Discussion Thread: DIP 1041--Attributes for Higher-Order Functions--Community Review Round 1

[Timon Gehr]

On 15.04.21 15:33, deadalnix wrote:
> On Thursday, 15 April 2021 at 01:15:34 UTC, Paul Backus wrote:
>> On Wednesday, 14 April 2021 at 23:51:33 UTC, deadalnix wrote:
>>> On Wednesday, 14 April 2021 at 22:23:38 UTC, Timon Gehr wrote:
>>>> For example, above, the semantics of `T[]` and `T delegate(S)` are 
>>>> not fully compositional, because they have special cases for `T = 
>>>> void`.
>>>>
>>>
>>> How is void delegate(S) a spcial case?
>>>
>>> Great post, BTW.
>>
>> You can't use `void` as a type on its own, but you *can* use it in 
>> certain specific contexts, like `void delegate(S)` and `void[]`. Those 
>> specific contexts are special cases: they're not derived from any 
>> general rule, but have to be spelled out explicitly in the language 
>> spec. (For example, https://dlang.org/spec/arrays.html#void_arrays)
> 
> idk, it seems to be that not being able to declare a void variable is 
> the special case. There are expression in D of type void, and they 
> compose like the rest of it.
> 

Officially, `void` "has no value". (Whatever that means precisely).
That makes it a special case throughout, even in cases where the type 
checker does not have to add specific checks for it because the same 
logic works to address both cases at once. In fact, that was probably 
the motivation: the design that was considered might have been to have 
separate syntax to declare functions that don't return a useful value 
and functions that do return something, then `void` was the "clever 
hack" that allows you to reuse certain compiler logic for "both cases", 
reducing the number of special cases in code. But there don't have to be 
two cases at all.

However, precisely which aspects of a non-compositional design are or 
are not the special cases seems to be a purely philosophical question; 
reasonable people may disagree. :)