On Tuesday, 8 February 2022 at 17:03:25 UTC, Doigt wrote:
> you'll see exactly that they also have a case for lambda expressions with no return values

Which example is that? Do they assign it to a value of a different type?

> Also you never addressed the JS side of my argument.

D allows a no-return lambda, but it doesn't allow you to assign it to a variable of a different type.

Javascript doesn't do static type checking at all, so obviously it would be different.

On 2/4/22 20:44, Paul Backus wrote:
> On Friday, 4 February 2022 at 17:59:40 UTC, Timon Gehr wrote:
>> On 04.02.22 18:18, Tejas wrote:
>>> On Friday, 4 February 2022 at 14:46:39 UTC, Paul Backus wrote:
>>>>     this(string y) => this(0, y);
>>>>     this(string y) { this(0, y); }
>>> ...
>>
>> If you have to violate common style guidelines in order to support a claim that the status quo is not so much worse, then probably the new syntax is actually significantly better. (Razvan did the same in the feedback thread, I don't get why people are doing this. Would this really fly, e.g., in Phobos?)
> 
> It's not super common, but it does show up. Some examples:
> 
> https://github.com/dlang/phobos/blob/v2.098.1/std/algorithm/setops.d#L901
> https://github.com/dlang/phobos/blob/v2.098.1/std/algorithm/iteration.d#L2051-L2052 
> 
> https://github.com/dlang/phobos/blob/v2.098.1/std/encoding.d#L487-L549
> https://github.com/dlang/phobos/blob/v2.098.1/std/datetime/systime.d#L9564-L9574 
> 
> https://github.com/dlang/phobos/blob/v2.098.1/std/math/exponential.d#L2748-L2755 
> 
> https://github.com/dlang/phobos/blob/v2.098.1/std/experimental/allocator/building_blocks/stats_collector.d#L199-L200 
> 

Thanks! I guess one way to interpret this is that there should be shortened method syntax to replace those. ;)

On Tuesday, 8 February 2022 at 17:11:19 UTC, Adam D Ruppe wrote:
> On Tuesday, 8 February 2022 at 17:03:25 UTC, Doigt wrote:
>> you'll see exactly that they also have a case for lambda expressions with no return values
>
> Which example is that? Do they assign it to a value of a different type?
>

I think the whole argument is that this will work in C#:

```d
int Value
{
  get => _value;
  set => _value = value; // This is okay
}
```

But it won't work in D according to this DIP:

```d
int value() => _value;
void value(int newValue) => _value = newValue; // This will not work
```

So instead everything becomes inconsistent like:

```d
int value() => _value;
void value(int newValue) { _value = newValue; } // This is ok obv.
```

However, now the code looks inconsistent and not intuitive at all.

On Wednesday, 9 February 2022 at 07:54:20 UTC, bauss wrote:
> On Tuesday, 8 February 2022 at 17:11:19 UTC, Adam D Ruppe wrote:
>> On Tuesday, 8 February 2022 at 17:03:25 UTC, Doigt wrote:
>>> you'll see exactly that they also have a case for lambda expressions with no return values
>>
>> Which example is that? Do they assign it to a value of a different type?
>>
>
> I think the whole argument is that this will work in C#:
>
> ```d
> int Value
> {
>   get => _value;
>   set => _value = value; // This is okay
> }
> ```
>
> But it won't work in D according to this DIP:
>
> ```d
> int value() => _value;
> void value(int newValue) => _value = newValue; // This will not work
> ```
>

I don't understand why the fact that C# has a special case for setters is relevant. Even though the setter in C# has 'void' return value, the actual return type of the assignment is still int. Consider:

var y = x.Value = 42;

which the compiler rewrites to something like:

x.set_Value(42);
var y = x.get_Value();

In D, you just return the new value from the setter:

int value(int newValue) => _value = newValue;

> So instead everything becomes inconsistent like:
>
> ```d
> int value() => _value;
> void value(int newValue) { _value = newValue; } // This is ok obv.
> ```
>
> However, now the code looks inconsistent and not intuitive at all.

I disagree. The proposed feature makes D overall more consistent.

On Wednesday, 9 February 2022 at 10:34:57 UTC, Max Samukha wrote:
>
> I disagree. The proposed feature makes D overall more consistent.

Yes it does, but not if both cases aren't supported.

And you shouldn't return the value from a setter, it should be void.

Which looks better?

```
int value() => _value;
void value(int newValue) => _value = newValue;
```

Or

```
int value() => _value;
void value(int newValue) { _value = newValue; }
```

The first case definitely looks better IMHO.

And yeah as you said void could just be int, but it shouldn't. The setter should be void.

It is almost universally accepted that setters should __never__ return anything and there's only one case where you might return from a setter and that is in fluid programming where you return the parent object to allow chaining.

So it's irrelevant that it works as a work-around.