Chandler CarruthandRichard Smith
94d2c1c6d4
We've talked about adding the title to the filename several times over the years and it seems really valuable. This requires us to compute a "slug" for the title spelling that can be part of the filename. Beyond that, we crossed 7000 recently, and so it seems likely that we will need to add digits sooner rather than later here, so this goes ahead and moves us to 6 digits so we don't have to adjust again for a reasonable length of time. To implement this and ensure we can sustain it going forward this adds a tool to our pre-commit that validates (and corrects if needed) the filename. In order to update everything and keep links working, there are a _lot_ of changes, but the most interesting for direct review are in `proposals/scripts`. Assisted-by: Antigravity with Gemini --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>
4.2 KiB
Support octal literals
Table of contents
Abstract
Support octal literals, mainly for migrating Unix file permissions. Reflects leads decision #6821.
Problem
Carbon currently does not support octal numeric literals, because they're very
rare, as previously decided in proposal
#143: Numeric literals.
However, as part of interoperability with POSIX file system calls such as
umask,
we want an easy way to express octal file permissions.
Background
Leads discussed support of octal literals in issue #6821: Support octal literals.
Unix file permissions written in octal are familiar to both programmers and non-programmers who have experience administering Unix-like machines. For example:
chmod OCTAL-MODE FILE...- POSIX
mode_tvalues, including the argument toumask.
However, they are are not likely to be readable to those unfamiliar with them, nor are they very common in code. We also expect these to be the primary use of octal numeric literals in Carbon.
Given these issues, proposal #143 rejected octal literals. Now, we're testing interoperability of POSIX file system calls, and we are considering octal literals as a potential solution.
Proposal #143 [discussed the Carbon-style 0o versus C++-style 0 prefix for
octal literals. The same logic still applies, so we will not address it here.
Proposal
Introduce support for octal literals using the 0o prefix (for example,
0o755), followed by one or more octal digits (0-7). This provides a very
simple lexical space for octal numbers, mapping clearly from C++ and building
consistently off the existing 0x... syntax for hexadecimal and 0b... syntax
for binary.
Future work
File permissions API
We may still provide a file permissions API in Carbon, for example as part of a
Core file system API. This proposal takes no stance on what that API should
look like. The only decision being made right now is that supporting octal
literals is worthwhile for interoperability and migration.
Rationale
This proposal effectively advances Carbon's goals by focusing on:
- Interoperability with and migration from existing C++ code: Providing a direct counterpart for C++ octal literals simplifies the migration of Unix file system code without needing to wait for a better file permission API.
- Code that is easy to read, understand, and write:
The explicit
0oprefix avoids the frequent confusion caused by C++'s leading0syntax, while maintaining consistency with hex and binary prefixes. - Software and language evolution:
The
0ooctal literal syntax is consistent with other literals. We don't expect it to hinder future language features.
Alternatives considered
No octal literals
Proposal #143 rejected octal literals. The main argument was that they are rarely used. However, the cost of octal literal syntax is low, and the benefit for C++ interoperability and migration is enough that we should add them.