Rant after trying Rust a bit

[Tofu Ninja via Digitalmars-d]

On Friday, 24 July 2015 at 00:55:35 UTC, Tofu Ninja wrote:
> On Thursday, 23 July 2015 at 20:09:34 UTC, Walter Bright wrote:
>> On 7/23/2015 7:49 AM, ixid wrote:
>>> If we had a clean sheet wouldn't it be better to have if 
>>> return a value and
>>> ditch ternary?
>>
>> Then we'd start seeing code like:
>>
>>     x = 45 + if (y == 10) { while (i--) z += call(i); z; } 
>> else { switch (x) { case 6: foo(); y; } + tan(z);
>>
>> I.e. the embedding of arbitrary statements within expressions. 
>> We already have some of this with embedded anonymous lambda 
>> support, and I've discovered one needs to be very careful in 
>> formatting it to not wind up with an awful unreadable mess.
>>
>> So I'd be really reluctant to continue down that path.
>>
>> Now, if you want to disallow { } within the embedded if 
>> statement, then the proposal becomes nothing more than:
>>
>>     ? => if
>>     : => else
>>
>> which is a potayto potahto thing.
>>
>> I agree that trivial syntax issues actually do matter, but 
>> having used ?: a lot, I have a hard time seeing embeddable 
>> if-else as a real improvement, in fact I find it more than a 
>> little jarring to see.
>
> I think I agree on the if else issue, seems arbitrary as we 
> already have ?:. Other statements as expressions have less 
> obvious meanings. The only part is that I wish you could have 
> blocks as expressions. The thing is with ufcs, it really should 
> be possible.
>
> For example the following does not compile:
> int a = {return 4;};
>
> but the following does:
> int a = {return 4;}();
>
> I know it's a really small difference, but with UFCS, I would 
> expect you the be able to omit the () and have the function 
> literal called automatically. Though I can see that this would 
> have problems with auto and knowing if it should be a function 
> pointer or to call the function.
>
> I guess what I would expect is "auto a = {return 4;};" to type 
> a to a function pointer, but if you explicitly type a to int 
> then the literal should be called.
>
> Does UFCS even apply to function pointers? I guess it is a 
> problem, it does not seem to be obvious when to call and when 
> to copy the pointer. I don't really know what should happen. I 
> think I read a dip a little while ago that might have addressed 
> this, but I don't really remember. I dont know, now that I have 
> written this, it seems to have more problems than I originally 
> thought.

Actually now that I think about it, I think I would expect auto a 
= { return 4;}; to type a to an int and call the function 
literal, and auto a = &{ return 4;}; to type a to a function 
pointer. I think that makes sense. Then if a is a function 
pointer auto b = a; would type b to a function pointer as well. I 
suppose UFCS really does not make sense to function pointers, but 
does make sense for function literals.

I expect {return 4;} to just be an anonymous function, not a 
pointer to an anonymous function. That way you can write alias f 
= {return 4;}; which would just be an alias to a function, which 
makes sense. I haven't thought about how this would apply to 
delegates.