On Wednesday, 9 February 2022 at 11:02:03 UTC, bauss wrote:

> 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;

Sorry, it doesn't look better to me. It looks as if the second function has an incorrect return type. It would look better if it was marked as a property setter and D handled property setters specially.

> ```
>
> 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.

Are we discussing this proposal, which is about unifying named and anonymous function syntax? Changing the way D handles property setters is a separate issue.

On Wednesday, 9 February 2022 at 12:14:22 UTC, Max Samukha wrote:
> It would look better if it was marked as a property setter and D handled property setters specially.
>

That's what it is. It's a property but @property is useless in D and you shouldn't use it, so maybe if @property actually worked in D then yeah I would agree.

But since @property doesn't really work and is somewhat obsolete then it should absolutely be supported to do the above regardless of whether it's a property or not.

And it also only looks wrong to you because you think of "N => N" being an expression only, BUT in this case it's not supposed to be an expression. It's supposed to be a shortened method syntax. So arguably any function statement should be valid after the "=>" and it indeed should be an "edge-case" for the "=>" operator.

void a() => b(); is valid in __all__ other languages that support it and thus it should be valid in D too, otherwise D again only gets a feature half-assed and falls behind everyone else.

Can we just for once in D not rely on being "hacky"?

On Wednesday, 9 February 2022 at 12:38:56 UTC, bauss wrote:

>
> And it also only looks wrong to you because you think of "N => N" being an expression only, BUT in this case it's not supposed to be an expression. It's supposed to be a shortened method syntax. So arguably any function statement should be valid after the "=>" and it indeed should be an "edge-case" for the "=>" operator.

Actually, if any type implicitly converted to the unit type, it would probably look pretty good to me. Not going to ever happen in D, though.

On Wednesday, 9 February 2022 at 12:38:56 UTC, bauss wrote:
> void a() => b(); is valid in __all__ other languages that

You can do that in D too, as long as b also returns void.

BTW it'd actually be a fairly simple change to the dip to allow these things. Instead of

`x => y` translated to `x { return y; }`

it could be translated to `x { return cast(typeof(return))( y ); }`


But casts are kinda harmful so i don't think that's a good idea in general. Of course it could special case it and say it does:

`x { static if(is(typeof(return) == void)) return cast(void) (y); else return y; }`


but idk.

On Wednesday, 9 February 2022 at 13:05:35 UTC, Adam D Ruppe wrote:
> it could be translated to `x { return cast(typeof(return))( y ); }`

actually wait i think this breaks return type inference so that impl would suck after all.

the thing that actually kicked off this implementation was writing to write:


@property foo() => this._foo;


which is an inferred return type so breaking that would be no good!

On Wednesday, 9 February 2022 at 13:05:35 UTC, Adam D Ruppe wrote:
> On Wednesday, 9 February 2022 at 12:38:56 UTC, bauss wrote:
>> void a() => b(); is valid in __all__ other languages that
>

Yes but the example would be b() is replaced by x = someparameter and then it fails.

On 09.02.22 14:46, Kagamin wrote:
> Another single valued method:
> ```
> static string getPipeName(int pid)
> {
>      return string.Format("{0}-{1}", _baseName, pid);
> }
> static string getPipeName(int pid) => string.Format("{0}-{1}", _baseName, pid);
> ```
> 88 and 79 characters, 10% saving.

I don't think this is primarily about saving characters.