Walter and I decided to kick-off project Elvis for adding the homonym operator to D.

Razvan Nitu has already done a good part of the work:

https://github.com/dlang/dmd/pull/7242
https://github.com/dlang/dlang.org/pull/1917
https://github.com/dlang/dlang.org/pull/1918

What's needed is a precise DIP that motivates the feature properly and provides a good proposal for it. I'm no fan of bureaucracy but we really need to be pedantic about introducing language features. Walter argued thusly in a PR, and I agree:

"I'm concerned that the elvis operator is not well understood, and we shouldn't be designing it in the comments section here. A DIP needs to be written. Things like operator precedence, side effects, type resolution, comparison with the operator in other languages, grammar changes, lvalues, how it would appear in the generated .di file if it isn't its own operator, etc., should be addressed."

A lowering looks like the straightforward approach, of the kind:

expr1 ?: expr2

==>

(x => x ? x : expr2)(expr1)

Who wants to join Razvan in Project Elvis?


Thanks,

Andrei

On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
> Walter and I decided to kick-off project Elvis for adding the homonym operator to D.
>
> [...]

This is honestly going to be a great addition.

Wait? You are saying D does not support this yet? Wow :D. I have been using this so often in work (PHP) so I can beleive I have not miss this

On Sat, Oct 28, 2017 at 2:39 PM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
>
>> Walter and I decided to kick-off project Elvis for adding the homonym operator to D.
>>
>> [...]
>>
>
> This is honestly going to be a great addition.
>

On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
> expr1 ?: expr2

So, what will the member function be called? «opElvis»? No…

On Sunday, 29 October 2017 at 10:08:41 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
>> expr1 ?: expr2
>
> So, what will the member function be called? «opElvis»? No…

opCast for bool.

-Steve

On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote:
>> So, what will the member function be called? «opElvis»? No…
>
> opCast for bool.

That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.

On Sunday, 29 October 2017 at 14:27:34 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote:
>>> So, what will the member function be called? «opElvis»? No…
>>
>> opCast for bool.
>
> That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.

That breaks down if you want do filter out invalid values where zero is a valid value. For instance if you have an integer type that tracks overflow:

calc(maybe_overflow_integer :? 0)

So casting to bool is a poor choice for the typical use context.

On Sunday, October 29, 2017 14:27:34 Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer
>
> wrote:
> >> So, what will the member function be called? «opElvis»? No…
> >
> > opCast for bool.
>
> That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.

opCast with bool is precisely how you already provide overloads for dealing with every other place in the language that a boolean condition is used - the ternary operator, assertions, if statements, while loops, and for loops (which I think is everything, but I could have missed something). As proposed thus far, the Elvis operator is just the ternary operator where the condition is reused as the first branch, so having it work with opCast fits in perfectly with everything else.

What would you be looking to do that does not fit in with this?

- Jonathan M Davis

On 10/29/17 10:35 AM, Ola Fosheim Grøstad wrote:
> On Sunday, 29 October 2017 at 14:27:34 UTC, Ola Fosheim Grøstad wrote:
>> On Sunday, 29 October 2017 at 11:23:19 UTC, Steven Schveighoffer wrote:
>>>> So, what will the member function be called? «opElvis»? No…
>>>
>>> opCast for bool.
>>
>> That means you cannot create your own type-safe filtering mechanism, but will be forced to provide opCast for bool.
> 
> That breaks down if you want do filter out invalid values where zero is a valid value. For instance if you have an integer type that tracks overflow:
> 
> calc(maybe_overflow_integer :? 0)
> 
> So casting to bool is a poor choice for the typical use context.

I would have expected Nullable!int to fit the bill, but unfortunately, opCast(bool) doesn't work on a null Nullable.

But certainly you can construct a type that does work.

-Steve

On Sunday, 29 October 2017 at 14:37:57 UTC, Jonathan M Davis wrote:
> everything, but I could have missed something). As proposed thus far, the Elvis operator is just the ternary operator where the condition is reused as the first branch, so having it work with opCast fits in perfectly with everything else.

I understand that it is being defined as a short hand for the ordinary ternary operator, but if you look at the use context the elvis-operator tend to be used to filter out invalid state.

So if casting to bool would test for validity then it would make more sense, but that is not the general case...

> What would you be looking to do that does not fit in with this?

I think it would be better to have a test for validity and use that for substituting in default values (which is what the elvis operator is typically used for).