I don't like the following designs #1440
Replies: 9 comments 20 replies
-
As somebody who finds it uncomfortable in C++, this syntax I'm almost willing to accept, due to the inconsistencies.
|
Beta Was this translation helpful? Give feedback.
-
I only agree the trailing return type consider generics I can accept keyword |
Beta Was this translation helpful? Give feedback.
-
why use it is a strongly typed language with a ILLUSION of weakly typed. |
Beta Was this translation helpful? Give feedback.
-
@inaryart I'm changing the title of this. The title was using a harsh way of expressing your opinion. Please bear in mind Carbon is not for everyone, but we do expect everyone to be kind and courteous. Review our code of conduct: https://github.com/carbon-language/carbon-lang/blob/trunk/CODE_OF_CONDUCT.md |
Beta Was this translation helpful? Give feedback.
-
current syntax to declare what about next |
Beta Was this translation helpful? Give feedback.
-
I disagree with this topic. (though I would prefer func or function instead of fn, and int32 instead of i32, but there are other topics for these keywords) |
Beta Was this translation helpful? Give feedback.
-
Why not use the walrus operator (
If the value is omitted then you have a declaration without an initialization:
If the type is omitted then can be inferred based on value:
Just seems like |
Beta Was this translation helpful? Give feedback.
-
Well the idea is probably to have type inference at some point. All modern languages use it in one way or another, so carbon should obviously have it to. And with this syntax, you can just skip the type definition instead of having to write auto. |
Beta Was this translation helpful? Give feedback.
-
The reason why Carbon can't afford the
syntax is actually quite simple. Doing so violates the following design principle:
The C/C++ declaration syntax requires you to have the type information at the stage of parsing. Consider a simple parser going through the tokens one by one, trying to figure out what whether it parses an expression or a declaration:
You might consider what happens if the parser is allowed to assume that identifier following another identifier is a sign on a declaration:
However, what if instead we chose a more complex example:
This is a tiny hint of unbounded lookahead. It gets worse once we start considering declarations of functions and pointers to functions. Note that in C and C++ parsers get away with using contextual information to reduce lookahead, which is also the reason why in those languages declaration must precede usage. |
Beta Was this translation helpful? Give feedback.
-
fn
and->
, obviously many times in one fell swoopbest than
var
and:
also redundant?best than
Beta Was this translation helpful? Give feedback.
All reactions