Replace Point { x: 3, y: 5 } with Point { x=3, y=5 }

[eloraiby]

+1, { x= 1, y=5} follows OCaml initialization. “:” is more suitable to designate types, and create inconsistence when used for assignment

[logician]

+1, because of the points made above, and the minimum post length is 20 characters.

[eridius]

The type of A(3) is irrelevant. The value constructor A(int) is declared with the syntax A(int) (within an enum), and invoked with the syntax A(int-expr). Similarly with structs, the value constructor Foo { x: uint, y: uint } is declared with the syntax Foo { x: uint, y: uint } (with a preceding struct keyword to indicate a struct definition follows) and invoked with the syntax Foo { x: uint-expr, y: uint-expr }. Also, trivially, the value constructor None is declared with the syntax None (within an enum) and invoked with the syntax None. And for record-structs, the value constructor Bar(uint, char) is declared with the syntax Bar(uint, char) (preceded by the struct keyword) and invoked with the syntax Bar(uint-expr, char-expr).

Offhand I cannot think of any type constructors that have an explicit declaration (e.g. not a built-in type constructor like tules or functions) where the invocation does not reasonably match the declaration.

[eloraiby]

eridus, if we are going to follow that logic we would stick with the C syntax for definition: struct Foo { x: 10, y:11 }. We spend more time reading code than writing it. As such, syntax must be short and clear. Assumimg that those who program have done some math at school, assignment is understood faster with “=” than with “:”.

[tbu]

If we’re going over math, we should have pascal-style assignments (:=), not C-like ones (=).

The problem with the = notation is that we’re not actually assigning something.

Struct { a: 5, b: 7 } is a value, no assignment is happening as opposed to what Struct { a = 5, b = 7 } would suggest.

The same way we can destructure a value like Struct { a: x, b: y } because we think of the whole thing as a value, where we can take out the a and the b.

[eridius]

Assumimg that those who program have done some math at school, assignment is understood faster with “=” than with “:”.

Except this isn’t assignment. This is declaration of value. Assignment requires an lvalue, but a field of a struct literal that’s being constructed is not an value.

That’s also a completely specious argument to begin with. Rust code is not math. The syntax used when learning arithmetic in school is not particularly relevant.

[dobkeratops]

If you wanted it to follow maths notation, maybe you’d use ‘=’ for immutable binding - initialisation and let would make sense, but mutative assignment might be a different operator. But its also well known in computing… = for mutative assignment. the real issue seems to be whats going to be unambiguous to the parser. (and it would be nice, IMO, if you could have anonymous structs or infer the struct-name from the signature in return expressions)

[liigo]

I would like to see “: always followed by type/bound, and = always followed by value”. So, +1 for =

[bluss]

I think I’ve stated this before, but I would like to see Point(x=3, y=5) and Struct and Enum construction always being done with parantheses. Why? Unify structs and enums more. Let the default Point(x=1,y=2) case be more similar to the related Point::new(s,t,u) convention. Lastly, the parentheses are more straight forward to align in code and you don’t have do debate if Point { x: 1, y: 2 } or Point{x: 1, y: 2} is the more consistent style. Both of those are weird to me; one with too much space and the other with too little.

[sam113101]

-1

I find “Point { x = 3, y = 5 }” to be too similar to a block with assignments inside of it. Sure, the compiler knows the difference, and the programmer would also know, but it’s simply less obvious when glancing at the code.

It would also look weird when destructuring.

[dhardy]

+1, because then : is consistently used for type specification and = for value specification (right?).

[errordeveloper]

Firstly, I find it very handy that this is close to JSON syntax and few other languages.

Secondly, I agree largely with @tbu. If the same syntax would be used for keyword function arguments, i.e. foo(bar: baz), whenever that’s implemented, would make a lot of sense together with struct literals.

[eloraiby]

@tbu, @eridius = or *= are the operators (always with equal) in math to bind/assign value to symbols/variables. “:” is weird and the arguments for it make no sense: A programming language is to be easier for a human to parse, if it is otherwise we would be still using assembly or lisp which is the most consistent. Care to say, you spend more time reading code than writing it, it’s easier and faster to spot and interpret a “=” where “:” is solely used for types. The current format is not as intuitive. I have no doubts that rust is going to be forked for this reason alone - as long as “:” is overused as it’s the case now -.

[cmr]

and the arguments for it make no sense

Invectives such as this are unproductive and not welcome here. The arguments laid out do make sense to me, whether you agree with them or not. If you want clarification, please ask for it.

[eridius]

You’re talking as if readability is some absolute that affects everyone the same way. It’s absolutely not. All you’re doing is rationalizing why you prefer = (and it is a rationalization; the syntax used in math rarely has any relation to the syntax used in non-numeric programming). Trying to claim that = is more “intuitive” than : is meaningless.

I have no doubts that rust is going to be forked for this reason alone

Hyperbole is not helpful.

[glaebhoerl]

I recognize the argument in favor of : of maintaining “literal syntax follows type declaration syntax”, but I find this sort of local consistency (between struct literals and declarations) to be less compelling than the global consistency of ": is type ascription, = is value assignment".

Indeed, if we follow the logic of local consistency, we should conclude that the field: type syntax of struct declarations is not actually intended to evoke type ascription. This is the syntactic form of structs, and the use of : is just a coincidence. But I don’t think that’s right.

[eridius]

: is type ascription, = is value assignment

Ah, but that’s one of the arguments against this change. A number of us, myself included, believe that the initialization expression of a field in a struct literal is not value assignment. See, for example, @tbu’s comment.

[glaebhoerl]

Eh, it’s the “value” half of it that’s significant, not the “assignment” I just couldn’t think of a better word. ": specifies types, = specifies values" or whatever, to use less loaded language. But obviously we can just agree to keep disagreeing.

[kmcguire]

I can read and interpret : and have never had a problem. I think : is easier to type. The = feels bulky and looks bulky. I like = in my statements because I think it helps me pick out initializers using the colon.

[liigo]

+1. I’d expect a “type” instead of a “value” after a :.