carbon-language / carbon-lang

Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
http://docs.carbon-lang.dev/
Other
32.35k stars 1.48k forks source link

Uniform way of declaring variable, function, class, struct etc. #1591

Open C-BJ opened 2 years ago

C-BJ commented 2 years ago

let main = fn()->i32 { } Functions also have types

let 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

jonmeow commented 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.

C-BJ commented 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.

Maybe look at the views of others in the community

chandlerc commented 2 years ago

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.

nacaclanga commented 2 years ago

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.

github-actions[bot] commented 2 years ago

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.