Am 17.01.19 um 01:41 schrieb Jonathan Marler:
> 
> A good summary of the issues with void. Maybe adding a bottom type enables some new clever semantics, but I would venture to guess that adding a real unit type would be even more helpful than a bottom type. I've had cases where being able to use void as a function parameter or a field would have made some of my templates much cleaner. Maybe we should focus on making void a real unit type before we try to add a bottom type?

I totally agree with this. I would love to see void becomming a real unit type!

I have already tripped over the fact that void is not a proper unit type several times. It makes generic function composition (and other generic constructions) so much more annoying: You always need to treat void as a special case.

Am 17.01.19 um 03:59 schrieb Meta:
> D has a couple of different unit types which all behave differently:
> 
> typeof(null), its sole value being null. It also happens to be the bottom type for all objects, pointers and arrays.
> 
> 
> void, which actually *does* have a single value - you just can't declare a variable with type void:
> 
> void main()
> {
>     auto v = new void[1];
>     pragma(msg, typeof(v[0])); // Prints "void"
>     import std.stdio;
>     writeln(v[0]); // Error: template std.stdio.writeln cannot deduce
> function from argument types !()(void)
> }
> 
> This may actually be a compiler bug/quirk; I'm not completely sure.
> 
> 
> Any enum with only 1 element:
> 
> enum Unit
> {
>     val
> }
> 

I have already resorted to using `struct Unit {}` as a proper unit type in the past. The problem with this however is that it is only convention. As soon as you have to interface with somebody else's code, you lost, because they all use void and expect you to use void.

> As an aside, the empty enum:
> 
> enum Empty
> {
> }
> 
> Is an uninhabited type similar to Bottom, but is not implicitly convertible to any other type, unlike Bottom.
> 
> 
> The empty struct:
> 
> struct Unit
> {
> }
> 
> Unit u;
> writeln(u); // Prints Unit()
> 
> 
> And probably more that I have missed

While all of this is true, in my opinion there should be one "canonical" unit type in the sense that it works as a proper unit type (it has only one value, you can declare variables of it) and it is implicitly returned from functions which do not have an explicit return statement (and are not inferred to return Tbottom, if that is added). The candidate for such a type would be void, but there are quite few things we'd need to fix as H. S. Theo explained somewhere in this thread.

Am 17.01.19 um 01:44 schrieb Nicholas Wilson:
> 
> Yes that is stupid. Does anyone write it now, given that it is already
> possible with LDC/GDC? No, because D is a pragmatic language, just
> because you can write something non-sensical doesn't mean that anyone
> will, especially when you have to go out of your way to do it.
> _We shouldn't be designing around the fact that you can do stupid things_.

I don't completely agree with this statement. If possible, as language authors we should try to design the language in such a way that it is impossible (or at least very hard) to do stupid things with it. Of course we also need to empower the user, but one has to find a good balance. If something is possible in the language, people will do it, however stupid it is.

The best example for this is what Walter always brings up:

```
#define BEGIN {
#define END }
```

I am very happy that this is not possible in D!

Am 16.01.19 um 23:32 schrieb Walter Bright:
> My trouble explaining the immediate value of a bottom type stems from my poor knowledge of type theory. Other languages aren't necessarily good role models here, as few language designers seem to know much about type calculus, either. I was hoping that someone who does understand it would help out!

I do actually think there is a lot of value in a bottom type. The
problem is that–as you mention–nobody stepped up and helped you with the
DIP, although in the reviews there has been a lot of substantiated (and
constructive) critique by people who (judging from their comments) seem
to know more about type theory than you.

Maybe the proper way forward is to reject the DIP and the current form and try again later once you got some help to bring it in proper shape?

As mentioned several times in this thread, there are quite a few other severe problems with D's type system (e.g. the problems with void, which H. S. Theo described). Maybe we should set up a working group (with at least some people who know a bit more about type theory) to tackle these problems (including a bottom type)?

Am 17.01.19 um 02:45 schrieb Walter Bright:
>
> My interest in a bottom type comes from wanting a sounder mathematical basis for types in D, but sadly nobody else seems interested, and this DIP is pretty much DOA.

I don't think this is true. At least I am very interested in giving D's types a sounder mathematical basis.

On 1/16/2019 10:38 PM, Johannes Loher wrote:
> I don't think this is true. At least I am very interested in giving D's
> types a sounder mathematical basis.

Good to hear!

On Wednesday, 16 January 2019 at 08:47:48 UTC, Johannes Loher wrote:
> By the way, Kotlin does basically the same thing. Kotlin does not have pointers, but it has optional types and the type `Nothing?` is a type which can hold exactly one value: `null`. This also means that it is basically a unit type. While it is not actually Kotlin's `Unit` type, it could have been. Similarly, should we decide to go down that road and add proper top, bottom and unit types, we could define
>
> ```
> alias Tbottom = typeof(assert(0));
> alias void = Tbottom*;
> ```

That is amazing. I love it.

On 1/16/2019 5:21 PM, H. S. Teoh wrote:
> You cannot write Derived.method as void, because then it wouldn't
> override Base.method.

Right. The language allowing one to write silly things is one thing, but requiring it in certain cases has a certain stench about it. I'm reminded of this:

  https://brevzin.github.io/c++/2019/01/15/if-constexpr-isnt-broken/

where the author notes that C++ requires silly things like "requires requires" and ".template".

As far as allowing the programmer to write stupid things, and relying on telling him to not do stupid things, endless experience shows that doesn't work very well. It's better that the language head off stupid things by design. For example,

    a < b < c

is a valid C expression, but stupid, because it doesn't do what you might think it does. D does not allow such expressions, so we don't have to add to the style guide "don't do that".

Of course, no language can stop every nut behind the wheel, but we're obliged to do what we can.

On 1/16/2019 8:52 PM, Johannes Loher wrote:
> In a later post, H. S. Theo describes some of the problems with void in
> more detail. What is your stance on actually fixing void from a type
> theoretical perspective? Do you think that is practical?

Too much water under that bridge.

On Wed, Jan 16, 2019 at 05:45:13PM -0800, Walter Bright via Digitalmars-d wrote: [...]
> My interest in a bottom type comes from wanting a sounder mathematical basis for types in D, but sadly nobody else seems interested, and this DIP is pretty much DOA.

Actually, I think most of the negative reactions come not from the technical problems of the DIP itself, but from the (perceived or otherwise) way it was handled, such as how it got to final review stage when it clearly needs more work. It may have sparked less outrage had it stayed in draft stage until the technical problems were ironed out.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.