Open C-BJ opened 2 years ago
Although this may be reminiscent of what happens behind the scenes, I think C++ developers are likely to find it a bit harder to switch to such syntax.
Although this may be reminiscent of what happens behind the scenes, I think C++ developers are likely to find it a bit harder to switch to such syntax.
Maybe look at the views of others in the community
FWIW, this style was something that I think at least a few of us have thought about at various points.
To expand a bit on what @jonmeow said about why we have not pursued it is that it isn't well aligned with our goals around interoperability and migration. C++, for better or worse, doesn't use this expression and assignment oriented style of declaring primary constructs. It just declares them with dedicated syntax. While Carbon adds introducer keywords to simplify the parsing, it doesn't try to change the basic pattern. Retaining some of the core design elements of C++, even if enhanced with keywords, is important to keep Carbon's human interoperability and migration.
So I think to consider this, we'd need both a signal of clear community interest in the direction and good rationale write-up around the benefits that the uniform approach would take.
Might be interesting for this discussion: https://odin.handmade.network/blog/p/2994-on_the_aesthetics_of_the_syntax_of_declarations.
That said, I do not think, that a syntax involving "let" is beneficial. If we would go for this, the keyword let should be removed, as it won't add much value.
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive
label. The long term
label can also be added for issues which are expected to take time.
This issue is labeled inactive
because the last activity was over 90 days ago.
let main = fn()->i32 { }
Functions also have typeslet animal = class{ };
Such a design can be extended to many aspects like import
It's just my own strange idea
Related discussion: https://github.com/carbon-language/carbon-lang/discussions/1542