> The ident: Type syntax let’s developers focus on the name by placing it ahead of its type annotation.
I agree with the sentiment, but that apostrophe is bugging me.
Language Design: Use 'ident: Type' not 'Type ident'
11–20 of 192 posts
Re: Language Design: Use 'ident: Type' not 'Type ident'
#12A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…
It's a historical problem in C. Originally, C had only built-in types. Structs were declared with
struct foo { int x; int y; };
foo*bar;
foo bar;
It's a big win if files are parseable without their dependencies. The Pascal/Modula/Ada family all are. I think Go is. Not sure about Rust, but it probably is. C and C++, no.
(The hacks for template syntax in C++ are painful to think about.)
Re: Language Design: Use 'ident: Type' not 'Type ident'
#13This feels a little nitpicky/idealistic, I don't think the post does a good job of conveying why it's more beneficial. > This means that the vertical offset of names stays consistent, regardless of whether a type annotation is present (and how long it is) or not. Why is this necessarily desirable? Strong typing systems have very expressive types, to the point where if something is typed correctly, most of the time my…
I've been using Rust a lot recently, which puts names before types and inputs before outputs, and I will absolutely attest to how much mental work is saved by ordering things this way. Skimming or reading Rust comes twice as easy as reading Java, and I do a lot of both. Sure it's an anecdotal report, but I have a real sense here that I feel compelled to report. As other posters have stated, this order makes parsing e…
Typescript also orders its parameters this way. Between all the Rust and Typescript vs Java and C++ code I've written, I really haven't found that either is better than other, it just seems like a largely arbitrary choice.
Making parsing easier for the compiler is a convincing benefit, would have been nice to see that mentioned in the article. I think that's a substantially stronger reason to prefer types after names. I'm not sure if I parse either faster or slower though.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#14A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…
It's a historical problem in C. Originally, C had only built-in types. Structs were declared with struct foo { int x; int y; }; which is easy to parse. Then came typedef. With user-defined types, foo*bar; isn't parseable with a LALR(1) parser until you've seen the definition of "foo". Even the ordinary case foo bar; needs more than one lookahead to parse. This is a headache for compilers, and a huge headache for anyt…
Ah, C not originally having typedefs explains why the syntax wasn't thrown out as too annoying to begin with. Syntax creep I guess.
An easy solution to the problem would be to do what e.g. Haskell does where case-sensitivity determines a type name. For better or worse, C didn't do that.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#15It is presented here that name before type is easier to read as a matter of fact. I’m not so sure. In math or languages where type info is optional, we often write “x = 5”. When type info is required, it is natural to evolve to “int x = 5”. Readers would naturally focus on the latter part. When we write “x: int = 5”, the type info is in the middle. We cannot skip it even when we just want to focus on the name and value.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#16You'd have to show me some data that one is easier to work with than the other, because fundamentally types _are_ names, and I find them just as expressive as variable names (many of which are just named after types, lets be honest). Even if I didn't, I don't think my brain struggles to read things in either order (or indeed in languages where types are rarely mentioned).
It's easier to parse if nothing else.
That seems to be the main problem. Otherwise it’s just something to get used to in my view.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#17Language Design Notes on Rust [0] from the same blog looks interesting too ... [0] - https://soc.me/languages/notes-on-rust.html
This is an interesting list.
Some of the things have been addressed (`extern crate`).
Many of the issues I disagree with: `Buf` is strictly better than `Buffer` (less typing, like `fn`). I have no issue with mixing `CamelCase::snake_methods`, and actually find it to be quite beautiful. The good parts of being Pythonic.
I would like to see the alternatives to turbofish. What exactly is the author suggesting? And what's wrong with `println!` and `format!` ? It isn't articulated.
`[]` misuse is bad, semicolons aren't consistent, `PathBuf` is inconsistently named, etc. Agree. `io::Result`, ...
Maybe there will be some cleanup in a future language edition.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#18Language Design: This stuff doesn't matter that much. Focus on more important things. Syntax isn't unimportant, but don't waste energy on trivial matters like these. Just pick something and people will get used to it. Focus on the semantics of your language - that's what really matters.
Actually, syntax IS important because a language has to be able to be read by both a human AND a computer, nowadays. One of the things that using ":" does is it makes what is "type" and what is "name" unambiguous to both human and computer. This is, famously, one of the failings of C/C++. Determining what is a type and what is a name is excruciatingly difficult.
Sure, but there's no arguing to be done there. Is the grammar context free? Ideally, can it be parsed with small constant lookahead? Yes? Cool, no further discussion needed.
I'd be more open to this kind of discussion if there was an ounce of actual research behind what makes syntax more/less readable. As it is, it's just a bunch of people arguing endlessly about their very specific preferences. Just pick something sensible and move on.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#19A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…
It's possible to argue here that the problem is not so much the order of type-then-name but the overloaded meanings of * and < at the grammar level.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#20Earlier quoted context omitted.
It's a historical problem in C. Originally, C had only built-in types. Structs were declared with struct foo { int x; int y; }; which is easy to parse. Then came typedef. With user-defined types, foo*bar; isn't parseable with a LALR(1) parser until you've seen the definition of "foo". Even the ordinary case foo bar; needs more than one lookahead to parse. This is a headache for compilers, and a huge headache for anyt…
Ah, C not originally having typedefs explains why the syntax wasn't thrown out as too annoying to begin with. Syntax creep I guess. An easy solution to the problem would be to do what e.g. Haskell does where case-sensitivity determines a type name. For better or worse, C didn't do that.
In Dylan all types were delimited with . Personally I always found that very aesthetically pleasing.