On Sunday, 9 July 2017 at 19:30:25 UTC, Meta wrote:
> I thought some more about the ramifications of having a Bottom type in D. Having a special type like this interacts badly with most aspects of D's generic programming capabilities, even on the simplest level. At the least we would probably have to create special cases everywhere in the compiler and/or libraries that check if the type we're working with is the bottom type. A few simple cases I can think of off the top of my head:
>
> alias Bottom = typeof(assert(0)); //for convenience
>
> Bottom*  pb; //Must be statically disallowed as this makes no sense
> Bottom[] ab; //ditto
> cast(Bottom)1; //ditto

Another case that we should probably just statically disallow:

alias ImmutableBottom = immutable Bottom; //Ditto for shared, const, etc.

This obviously doesn't make any sense anyway.

On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:
> On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
>> It's no more of a hack than leaving assert(0) in release code.
>
> I wouldn't argue that. I do argue it's a hack compared to the principled solution of a bottom type.

I would argue a type hack in the compiler doesn't compare to the principaled use of existing syntax and semantics  ;)

-Steve

On 7/9/2017 12:30 PM, Meta wrote:
> [...]

Some great info and links. It's a compelling argument to add a bottom type.

On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
> > It's no more of a hack than leaving assert(0) in release code.
> 
> I wouldn't argue that. I do argue it's a hack compared to the principled solution of a bottom type. -- Andrei

I like out{ assert(0); } for pretty much the same reasons as Steven
lists. The biggest pro is that **the language already supports it*.
Contract syntax already is meant to signal intent, and assert(0) signals
"never gets here". You can't find a better solution than this. All the
other alternatives require adding even more baggage to an already
heavy language, or compiler voodoo to recognize a particular pattern of
defining a type.  I'd say out{assert(0);} is the principled solution --
expressing something the current language can already express, and it's
the other alternatives that are "exotic".


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

On 7/9/2017 1:24 PM, Meta wrote:
> Another case that we should probably just statically disallow:
> 
> alias ImmutableBottom = immutable Bottom; //Ditto for shared, const, etc.
> 
> This obviously doesn't make any sense anyway.



Wouldn't `immutable(Bottom)` simply resolve to `Bottom`?

On Sunday, 9 July 2017 at 21:32:31 UTC, Walter Bright wrote:
> On 7/9/2017 1:24 PM, Meta wrote:
>> Another case that we should probably just statically disallow:
>> 
>> alias ImmutableBottom = immutable Bottom; //Ditto for shared, const, etc.
>> 
>> This obviously doesn't make any sense anyway.
>
>
>
> Wouldn't `immutable(Bottom)` simply resolve to `Bottom`?

I was thinking about that (and in fact, making Bottom a "viral" type in the same way that NaN is a viral value), but it's not really worth it and we might as well make it an error. It can't occur in any template code if we disallow passing Bottom as a template argument, e.g., the following would fail:

alias Pointificate(T) = T*;
alias Immutable(T) = immutable T;

//Error: cannot pass Bottom as a template type argument
alias PointerToBottom = Pointificate!Bottom;
alias ImmutableBottom = Immutable!Bottom;

So the only place left where we could make a modified Bottom type would be doing `alias Immutable Bottom = immutable Bottom` and the like. It doesn't really matter either way, I don't think, but we might as well keeps things streamlined and just disallow everything to do with Bottom that we don't like. Unless there's a compelling reason to be able to apply immutable, shared, etc. to Bottom (and I don't see how there can be as you can never have a value of type Bottom that could be immutable, shared, etc. anyway) we should just disallow it.

Some functional languages do allow you to create things like `Either!(T, Bottom)` (from the Reddit thread: "Sometimes you have a generic procedure over a sum type and you want to pass it a single thing: `Either a Bottom` is isomorphic to a.") but I don't see a reason for us to ever need to do that.

On Sunday, 9 July 2017 at 11:26:27 UTC, Steven Schveighoffer wrote:

> The one disadvantage, is that -release removes contracts. So in this particular case, the out contract should remain.

Doesn't the compiler know about an out contract even with -release? I don't understand why -release would prevent the relevant information from being passed to the compiler.

On 07/09/2017 03:12 PM, Walter Bright wrote:
> On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
>> We should use typeof(assert(0)) for Bottom. There is precedent - there is no name for typeof(null).
> I had forgotten about the typeof(null) thing. You're right. But there are some issues. What do we do with:
> 
>      typeof(assert(0))* p;
> 
> ? What does that mean?

That would be a pointer that may only be null - a consequence of the typeof(assert(0)) being uninstantiable.

Generally I'm not too worried about constructs like typeof(assert(0))[], typeof(assert(0))*, use in templates etc - we don't need to "design" these cases, their behavior flows from the properties of typeof(assert(0)) itself.

Similarly, I don't recall ever there being a problem with typeof(null)*, typeof(null)[], people complaining they passed typeof(null) to a template where it did bad things, etc.


Andrei

On 07/09/2017 03:30 PM, Meta wrote:
> alias Bottom = typeof(assert(0)); //for convenience

Speaking of which, I think we shouldn't give it a name, same as typeof(null). Just keep it typeof(assert(0)). Then wherever it occurs it is immediately clear it has a special status requiring a second look (which it does). -- Andrei

On 07/09/2017 06:32 PM, Andrei Alexandrescu wrote:
> On 07/09/2017 03:30 PM, Meta wrote:
>> alias Bottom = typeof(assert(0)); //for convenience
> 
> Speaking of which, I think we shouldn't give it a name, same as typeof(null). Just keep it typeof(assert(0)). Then wherever it occurs it is immediately clear it has a special status requiring a second look (which it does). -- Andrei

And btw this is technically a breaking change because somebody somewhere is liable to write code like:

void fun()
{
   ...
   return assert(0);
}

I'm not too worried about it though, and in fact we may even still accept it because hey typeof(assert(0)) converts to anything so how about it even converts to void.


Andrei