Hacker News Reader

Comment by hbossy | Hacker News Reader

    var r : i32;

How is this any better than

    int32_t r;

? all I see is additional, unnecessary keyword to type.

View on HN

    abc * xyz;

Depending on what abc is (variable or type name) it can be either a multiplication or pointer variable declaration. With the new syntax ambiguity is reduced.

This might not be a huge issue for people reading code (because in context it should be pretty obvious), but for compiler it means that type information is required to parse code and compiler stages get mixed together.

I can't see details of the Carbon syntax for pointer, array and function types, but this is where Rust's type syntax really excels compared to the C++ style.

   let foo : & fn(&[MyType], i32) -> String = ...

(a reference to a function that takes a slice and a 32bit signed integer as arguments and returns a string)

is dramatically simpler than the C/C++ equivalent.

More subjectively, I find `var` or equivalent makes code much easier to read, because you can scan for variable declarations much more easily. With C++ code, almost any token could be a variable declaration and you have to think about the type even if you wouldn't otherwise care about it. It also allows you to have inferred types without a separate auto keyword.

Why isn't it

    let foo : & (&[MyType] -> i32) -> String = ...

Like in Haskell? Seems having both `fn` and `->` is unnecessary?

Well the syntax for declaring a function in Rust is:

    fn foo_bar(foo: &[MyType], bar: i32) -> String { ... }

so probably to match that.

I believe Haskell does something clever such that there is no difference between a function that takes two parameters, and a function that takes one parameter and returns a function that takes the second parameter. This isn't the case in Rust. Those would be distinct types and the latter would be called differently to the former. So I'm not sure that the Haskell syntax would work for Rust.

It's definitely as hard to read as C++ though.

I really disagree. Specifically when you have types nested within one another the complexity doesn't increase much. Whereas with C++ style declaration it quickly becomes type soup.

To avoid https://cdecl.org/ is good reason enough. Enjoy parsing middle-out, I’ll take a keyword any day of the week.

On that note, is there any recently created programming language decided to go with that type before name?

prefixing with the type wouldn't require middle-out though.

I think by using `var` keyword you have the potential to inherit the type without changing too much the syntax, in rust you could omit the type if the compiler can inherit the type, that saves you a lot of typing in the future, but you could argue that it makes harder to read the source code without any tool.

The word you wanted was "infer" not "inherit"

For example "if the compiler can inherit the type" should read "if the compiler can infer the type".

It is easier to parse. Less ambiguity with something like int32_t r(); what is that?

I would argue that convenience of users is more important than easy of parsing.

C type declaration syntax isn't easy to read for humans, as demonstrated by demand for projects such as <https://cdecl.org/>.

Ask a non programmer what each means or measure the time newer devs take to understand it. On its own maybe its easier but I suspect for people its the same or saying var is easier.

You type about the same number of characters. Now imagine you wanted to declare the value to be immutable.

Its 5 extra characters actually.. because any sensible C++ project has i32 etc defined.

The type omission version isn't very useful, as this type of code is difficult to read later. Generally end up regretting using auto, and end up converting it to the actual type, except with iterators or nasty templates.

That hasn't been my experience, personally. In fact, sometimes I wish decltype was easier to use, to declare type dependencies.

That's only true because they used build-in int type. Why would I prefer to use: var inst : MyClass; over MyClass inst;

> all I see is additional, unnecessary keyword to type.

Not to mention the weird appearance of uppercase letters in function calls (Print ?)

Reply on news.ycombinator.com