Discussion Thread: DIP 1043--Shortened Method Syntax--Final Review

Quirin Schroll qs.il.paperinik at gmail.com
Tue Jul 19 17:59:32 UTC 2022


On Thursday, 16 June 2022 at 06:54:39 UTC, bauss wrote:
> On Wednesday, 15 June 2022 at 13:40:20 UTC, Paul Backus wrote:
>> ...
>
> On Wednesday, 15 June 2022 at 13:49:04 UTC, Steven 
> Schveighoffer wrote:
>> ...
>
> Thank you, like I said I wasn't sure if that was supported by 
> the name of `AssignExpression` and whether it would work, but 
> seems like everything is good.
>
> So from my point of view then everything is okay.
>
> On Wednesday, 15 June 2022 at 13:50:28 UTC, Adam D Ruppe wrote:
>> On Wednesday, 15 June 2022 at 13:40:20 UTC, Paul Backus wrote:
>>> This already works--both for the new syntax, and for the 
>>> existing arrow-lambda syntax, and even for functions with an 
>>> explicit `return` statement:
>>
>> Indeed, though if one of them doesn't return void:
>>
>> int a() => 0;
>>
>> void b() => a();
>>
>> This will "Error: cannot return non-void from `void` function"
>>
>> You can `void b() => cast(void) a();` to explicitly discard 
>> the return value and then it builds.
>>
>> I'm perfectly fine with that the way it is, just mentioning 
>> for factual completeness.
>
> I'm perfectly fine with this not working, because I think that 
> could lead to subtle bugs.
>
> I'm a strong believer of that if a function returns a value 
> then you must use that value and should only discard it if 
> absolutely necessary or if you're debugging.

This has never been true. Most functions fall exactly into one of 
these two categories:
* Returns void.
* The return value is the purpose.

A rather small fraction of functions returns a value one is 
conditionally interested in. An example is C’s `printf` or .NET’s 
[MessageBox.Show](https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.messagebox.show) where *sometimes* you’re interested in the result and sometimes it is clear from the code what the result will be. However, one almost never confuses the times when the result is relevant with those when they’re not.

A minute fraction of functions returns a value that is not the 
(only or primary) purpose of the function, e.g. an error code, 
but ignoring it is wrong in almost all cases. Those functions 
should have a 
[`@mustuse`](https://dlang.org/spec/attribute.html#mustuse-attribute) annotated return type. Implicit discard of `@mustuse` through void returning `=>` without `cast(void)` should be an error.


More information about the Digitalmars-d mailing list