On Monday, 12 October 2020 at 11:55:38 UTC, Imperatorn wrote:
> On Monday, 12 October 2020 at 08:52:22 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 12 October 2020 at 06:41:26 UTC, Imperatorn wrote:
>>> The empty type cannot be a return type
>>
>> It can be a return type, but you probably meant that a function with a bottom type as a return value does to return normally.
>>
>> A function that always returns by exception would have a bottom type as the return type.
>
> "A function whose return type is bottom cannot return any value, not even the zero size unit type. Therefore a function whose return type is the bottom type cannot return."

https://docs.python.org/3/library/typing.html#typing.NoReturn
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-nothing.html
https://doc.rust-lang.org/std/primitive.never.html

On Monday, 12 October 2020 at 11:55:38 UTC, Imperatorn wrote:
> "A function whose return type is bottom cannot return any value, not even the zero size unit type. Therefore a function whose return type is the bottom type cannot return."

It does not return using the normal path is what they mean, so the expression takes no value.

On Monday, 12 October 2020 at 12:10:39 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 October 2020 at 11:55:38 UTC, Imperatorn wrote:
>> "A function whose return type is bottom cannot return any value, not even the zero size unit type. Therefore a function whose return type is the bottom type cannot return."
>
> It does not return using the normal path is what they mean, so the expression takes no value.

Please note that the bottom type as a return type does not describe what the function does. It describes what the type of the expression is at the call-site.

On Monday, 12 October 2020 at 07:57:11 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 11 October 2020 at 20:37:56 UTC, Paul Backus wrote:
>>
>> Given that null references for classes are widely considered a "billion dollar mistake" [1], the comparison does not exactly fill me with confidence.
>
> Is that really a valid comparison, though?  Doesn't the issue with null references for classes stem from memory safety concerns?
>
> I don't quite see how that applies in the case of types, any more than NaN is a safety issue for floating point numbers.

The issue with null references is not related to memory safety. NullPointerException in Java is not a memory-safety error, for example. The issue with nullable references is that you have to check every reference for null before you use it, or your program will crash.

By contrast, NaN will not crash your program if you forget to check for it before using it in an expression.

On Monday, 12 October 2020 at 14:11:22 UTC, Paul Backus wrote:
> By contrast, NaN will not crash your program if you forget to check for it before using it in an expression.

That depends. It is not uncommon to have two sets of floating point operations with/without exceptions. You also have something called signalling NaN (sNaN).

Anyway, the correctness issues in floating point expressions are quiet complicated in reality.

On Monday, 12 October 2020 at 14:11:22 UTC, Paul Backus wrote:
> The issue with null references is not related to memory safety. NullPointerException in Java is not a memory-safety error, for example. The issue with nullable references is that you have to check every reference for null before you use it, or your program will crash.
>
> By contrast, NaN will not crash your program if you forget to check for it before using it in an expression.

Right.  I'm just not sure I follow why the ø Stefan is defining wouldn't behave more like NaN than a null pointer.

On Monday, 12 October 2020 at 14:46:14 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 12 October 2020 at 14:11:22 UTC, Paul Backus wrote:
>> The issue with null references is not related to memory safety. NullPointerException in Java is not a memory-safety error, for example. The issue with nullable references is that you have to check every reference for null before you use it, or your program will crash.
>>
>> By contrast, NaN will not crash your program if you forget to check for it before using it in an expression.
>
> Right.  I'm just not sure I follow why the ø Stefan is defining wouldn't behave more like NaN than a null pointer.

Since ø is not a type, I assume that you will get an error if you try to use it for anything that requires a type--for example, declaring a variable, or asking for its .sizeof.

If this is not the case, I invite Stefan to correct me.

On Monday, 12 October 2020 at 15:03:07 UTC, Paul Backus wrote:
> On Monday, 12 October 2020 at 14:46:14 UTC, Joseph Rushton Wakeling wrote:
>> On Monday, 12 October 2020 at 14:11:22 UTC, Paul Backus wrote:
>>> The issue with null references is not related to memory safety. NullPointerException in Java is not a memory-safety error, for example. The issue with nullable references is that you have to check every reference for null before you use it, or your program will crash.
>>>
>>> By contrast, NaN will not crash your program if you forget to check for it before using it in an expression.
>>
>> Right.  I'm just not sure I follow why the ø Stefan is defining wouldn't behave more like NaN than a null pointer.
>
> Since ø is not a type, I assume that you will get an error if you try to use it for anything that requires a type--for example, declaring a variable, or asking for its .sizeof.
>
> If this is not the case, I invite Stefan to correct me.


You cannot create a variable of type ø.
ø myVar; is invalid.
You cannot ø as a returnType or as a parameter type.
So a functiondeclatation like ø fn(int x) or int fn(ø x) is invalid.

But you can ask for it's size.
ø.sizeof == 0.
For it's members
__traits(allMembers, ø) == []
....
And I think that's all of the introspection I currently support.

__traits(getAttributes) is currently not available anymore as I need to define, a type which can hold anything  (and not just types) for that to work.

On Monday, 12 October 2020 at 15:10:55 UTC, Stefan Koch wrote:
> ø.sizeof == 0.
> For it's members
> __traits(allMembers, ø) == []
> ....
> And I think that's all of the introspection I currently support.
>
> __traits(getAttributes) is currently not available anymore as I need to define, a type which can hold anything  (and not just types) for that to work.

I think you need to ask yourself why you need this?
You can also look at how other languages do type variables.

One clean solution is to bind them to Object and subclasses of Object, but since Object is not a subtype of all D types you could use __bottom__. I don't really see a good argument for why __bottom__ cannot be used?  You cannot instantiate __bottom__.

If you went for something more generic like AST-node pointers then it would make sense, but then you could just go with null... basically representing "is waiting for a value" or "under construction".

But then you also need to figure out if you want to represent incomplete types.

On Monday, 12 October 2020 at 15:44:44 UTC, Ola Fosheim Grøstad wrote:
> One clean solution is to bind them to Object and subclasses of Object, but since Object is not a subtype of all D types you

supertype...