I don't why should use => for match case or -> for return seriously these are so painfully in typing someone suggest to Rust's core team to change it and make this more type friendly 
This change can't be made because it would be a massive breaking change. Allowing both syntaxes would also create more confusion than just keeping it as it is now.
3 Likes
Yeah , it's massive but it can be usefull with briefing syntax , and if it's good change so must happen there before groving . Anyway that's happen in myself it can be easier in typing 
Ok, but since Rust has strong stability guarantees, this change will never happen.
Either way, is there a particular reason why you think that this change would make it easier to type? I don't see any noticable differences, = is right next to -, and that is the only change you seem to be proposing
2 Likes
It depends on keyboard layout.
2 Likes
There's no different between those but maybe can : instead than => on match and no symbol for returning instead than -> . Maybe it's wrong thought but I would like ask other opinion
True, I forgot about that.
: is usually used for type annotations, so this would be conflating two different parts of the language. (It's bad enough that : is used to initialize and pattern match on fields)
This seems more tractable, but then we would loose the nice correspondence to closures, where the return type of a closure can be specified like so, |args| -> ret { body }
1 Like
Never mind keyboard layout. It's all the same to me.
But I have often found myself typing => instead of -> and vice-versa.
I have no problem with what we have, that's just something for me to get used to. But it makes me wonder why they are different in the first place?
They're different, because they mean different things. I get that they can be confused, but it's not very different from confusing : with ; or { with (, or ' with ", or / with \.
match foo {
_ => || -> () {},
}
At this point, there's zero chance Rust will change any of its fundamental syntax. It has its quirks, and everyone has their opinion about what's ugly or unreadable, but the syntax has been stabilized. Any changes now have a huge cost to the language (invalidating books, tutorials, forum posts, SO answers, making all of existing code "legacy", causing ton of churn and confusion, etc.), and Rust wants to uphold its guarantees of stability and backwards-compatibility. Rust already has a reputation of changing too much from just relatively small and backwards-compatible syntax additions it makes.
If you're very unhappy with the syntax, the best bet would be to create a new compile-to-Rust language. Similar to what CoffeeScript and TypeScript did to JavaScript.
3 Likes
That is beautiful. However in my ideal language such "line noise" would not be anything one could compile 
I still don't see why they need to be different. In both cases we have "The thing on the right results in the thing on the left." Would it really be ambiguous to have:
match foo { _ => || => () {}, }
or
match foo { _ -> || -> () {}, }
instead?
Clearly I am missing a point here.
I don't like this because -> is for types and => for values.
However I do agree that there's a bit too many syntax variations for similar things. IMO the body of a match is effectively just a list of closures:
match foo
{
1 => a,
x => { b; c }
}
could just as well be written as
match foo
{
|1| a,
|x| { b; c }
}
Dude seriously that wasn't point , I choose the language for developing for it's feature and and just want know other opinion about this , and syntax isn't feature , and if compare to some language like go and c++ it can be more easy not with js, ts and etc. Anyway Ok! I do Rust and keep going with its syntax🙇
I for one am very glad that it is not. What you suggested there looks very obtuse.
As it stands what I immediately understand from the source is that when "foo" is a "1" I get an "a", and so on.
When you introduce that closure/lambda function notation I get a totally different concept in my mind, that when "foo" is an "1" I'm calling an anonymous function with a parameter of "1" that returns an "a"
That is a whole different mechanism conceptually. And not what I want to do. I don't want to be calling any function there.
What actually goes on under the hood I have no idea, but I want to write what I mean.
1 Like
That's not what it means, there's no (explicit) calling of the closure in the code. I'm declaring a closure that can only take 1 as parameter.
I see it the other way round. It's the same concept even if it's implemented differently under the hood.
A match arm is IMO just a closure that is called in the case where the value matches the pattern of that arm.
In both cases (closure, match arm) you are going from a pattern to an output value using a block of code, the only difference being that for a closure, the pattern must be exhaustive. But that could easily be relaxed in the context of a match.
My only understanding of closures involves there being a function in play. As described by wikipedia:
In programming languages, a closure, also lexical closure or function closure, is a technique for implementing lexically scoped name binding in a language with first-class functions. Operationally, a closure is a record storing a function[a] together with an environment.
By introducing that lambda function notation "|x|" you have introduced all that conceptual baggage of functions, parameters, closure, where what we actually want is to simply get some value in response to some other input value. A glorified case statement, a look up table, a syntactic rearrangement of "if", "else" clauses.
Whether this any actual function calling going on or not does not matter. Certainly if there isn't I don't want to see functions appearing in my source.
Having programmed for decades in procedural languages and only having heard of a "closure" for the first time a few years back when I got into Javascript I'm not even sure why we need them and why people insist on obfuscating their code with them.
You could probably even make it match foo ( () -> () -> () () ).
The point is that reduction in number of unique chars used is not an improvement in readability, because while it may technically be unambiguous to a machine given a carefully specified grammar, it gives fewer clues to humans who do not exactly parse it char by char.
There is in general an inherent trade-off between ease of writing and ease of reading. When writing you know what you mean, so you want to type the least amount of information and have the computer figure it out. When reading you don't want to spend effort deciphering "compressed" code, you'd rather have everything clearly spelled out.
It's expected that a language will have a mix of complaints that "it's too annoying to write" and "it's too hard to read" (unless it goes full-Perl and satisfies only one side).
4 Likes
Actually kornel, I totally agree.
Languages like lisp show we can get by with a minimal set of punctuation chars. No thanks
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.