Project Elvis

[meppl]

On Friday, 10 November 2017 at 05:23:53 UTC, Adam Wilson wrote:
> On 11/6/17 12:20, Michael wrote:
>> I can't quite see why this proposal is such a big deal to 
>> people - as
>> has been restated, it's just a quick change in the parser for 
>> a slight
>> contraction in the code, and nothing language-breaking, it's 
>> not a big
>> change to the language at all.
>>
>> On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
>>> I am all for the Elvis operator, however I have two 
>>> reservations about
>>> it. The first is that I don't see much use for it without a
>>> null-conditional. The second is that the current proposed 
>>> syntax ?: is
>>> MUCH to easily confused with ?.
>>>
>>> This is not easy to read: obj1?.obj2?.prop3?:constant.
>>>
>>> When designing syntax sugar, ergonomics are very important, 
>>> otherwise
>>> people won't use it. Microsoft spent a LOT of time and 
>>> treasure to
>>> learn these lessons for us. I see no reason to ignore them 
>>> just
>>> because "we don't like Microsoft"
>>>
>>> My proposal would be to copy what MSFT did, expect that I 
>>> would I
>>> would introduce both operators at the same time.
>>>
>>> Syntax as follows: obj1?.obj2?.prop3 ?? constant
>>>
>>> In practice I don't see much use of the idiom outside of 
>>> null's. The
>>> ONLY other thing that would work there is a boolean field and 
>>> you
>>> might as well just return the boolean itself because the 
>>> return values
>>> have to match types.
>>
>> I feel this is kind of embellished somewhat. When you write
>>
>>> This is not easy to read: obj1?.obj2?.prop3?:constant.
>>
>> you're not separating it out as you do when you write your 
>> preferred
>> version:
>>
>>> Syntax as follows: obj1?.obj2?.prop3 ?? constant
>>
>> How is
>>
>>> obj1?.obj2?.prop3 ?: constant
>>
>> not as easy to read as
>>
>>
>>> obj1?.obj2?.prop3 ?? constant
>>
>
> You're right, I didn't, that was intentional, because sometimes 
> people write things like that. And it took a while for anyone 
> to say anything about it. That is my point.
>
> But that's the thing. The ?? is significantly more obvious in 
> the condensed version.
>
> This is something that a UX designer would recognize instantly, 
> but human factors are very definitely not our strong skill as 
> engineers. FWIW, my human factors experience comes from the 
> deep study of airline crashes that I do as a pilot.
>
>> to me they are the same in terms of readability, only with ?? 
>> you have
>> greater chances of mistyping and adding a second ? in there 
>> somewhere,
>> whereas the ?: is just a contraction of the current syntax, I 
>> really
>> don't think it's that difficult, so I'm not sure what people's 
>> hang-ups
>> are, but I don't think the argument that ?? is easier to read 
>> than ?:
>> holds any weight here, because one *is* a change to the 
>> language, and
>> the other is a change to the parser and a contraction of a 
>> standard
>> convention.
>>
>
> Two things. ?: is ALSO a change a to language (lexer+parser). 
> As to the whole "it's no more likely to typo the colon than the 
> question" argument, sure, but that depends on the keyboard 
> layout more than anything else, what works for you may not work 
> elsewhere. And in either case, it's an easy compiler error. So 
> you don't win anything with the ?:, but you win readability 
> with the ??. MSFT spends a LOT of time studying these things. 
> It would be wise to learn for free from the money they spent.

I still dont get your point. Are you sure `??` isn't more 
readable for you, because you are just used to it?

I think `?:` makes more sense to me and people who learn the D 
programming language.
At least As log as `null` becomes `false` and non-null-pointer 
becomes `true`.

If the operator shall check for `null` only, I would be fine with 
`??`.
Because then it wouldn't be a true shortcut of  
https://dlang.org/spec/expression.html#ConditionalExpression  
anymore

I wonder what Mr. Bright and Mr. Alexandrescu would say about the 
request to implement both, `??` and `?:`.