October 11, 2020
On Sunday, 11 October 2020 at 18:09:28 UTC, Stefan Koch wrote:
>
> Instantiating a template for just one more additional value?
> Having to drag this bool around in ctfe?
> Having to check it every time when you do an is-exp?
>
> that's crazy.
> Especially when I have to choice to define an empty type.

It doesn't have to be a template; it could be a __type*, or something else built-in. The point is that code working with __type variables shouldn't be *required* to add null checks everywhere to account for the possibility of ø. Nullability should be opt-in.
October 11, 2020
On Sunday, 11 October 2020 at 18:18:24 UTC, Paul Backus wrote:
> On Sunday, 11 October 2020 at 18:09:28 UTC, Stefan Koch wrote:
>>
>> Instantiating a template for just one more additional value?
>> Having to drag this bool around in ctfe?
>> Having to check it every time when you do an is-exp?
>>
>> that's crazy.
>> Especially when I have to choice to define an empty type.
>
> It doesn't have to be a template; it could be a __type*, or something else built-in. The point is that code working with __type variables shouldn't be *required* to add null checks everywhere to account for the possibility of ø. Nullability should be opt-in.

ø is a special case that shouldn't happen to often.

You are free to ignore the possibility of it being null.
Just like with classes which almost no one checks with class is null.

October 11, 2020
On Sunday, 11 October 2020 at 19:45:06 UTC, Stefan Koch wrote:
>
> ø is a special case that shouldn't happen to often.
>
> You are free to ignore the possibility of it being null.
> Just like with classes which almost no one checks with class is null.

Given that null references for classes are widely considered a "billion dollar mistake" [1], the comparison does not exactly fill me with confidence.

Is there a serious problem with using __type* when you need something nullable, and __type otherwise? It seems like the best of both worlds to me.

[1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
October 11, 2020
On Sunday, 11 October 2020 at 20:37:56 UTC, Paul Backus wrote:
> On Sunday, 11 October 2020 at 19:45:06 UTC, Stefan Koch wrote:
>>
>> ø is a special case that shouldn't happen to often.
>>
>> You are free to ignore the possibility of it being null.
>> Just like with classes which almost no one checks with class is null.
>
> Given that null references for classes are widely considered a "billion dollar mistake" [1], the comparison does not exactly fill me with confidence.
>
> Is there a serious problem with using __type* when you need something nullable, and __type otherwise? It seems like the best of both worlds to me.
>
> [1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

I am going to give this talk a listen.

__type can always be invalid, getting the super type of "object" or "int" for example would yield a type which is not a type.
I could have them return __type* .... I need to experiment with this.
October 12, 2020
On Sunday, 11 October 2020 at 12:18:59 UTC, Stefan Koch wrote:
> Good Morning,
>
> today I would like to write about something which came up while implementing type functions.
>
> [...]

You have a typo here:
But Ø cannot be ⊥, because ⊥ can be a valid return type

The empty type cannot be a return type
October 12, 2020
On Sunday, 11 October 2020 at 20:37:56 UTC, Paul Backus wrote:
> On Sunday, 11 October 2020 at 19:45:06 UTC, Stefan Koch wrote:
>>
>> ø is a special case that shouldn't happen to often.
>>
>> You are free to ignore the possibility of it being null.
>> Just like with classes which almost no one checks with class is null.
>
> 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.
October 12, 2020
On Sunday, 11 October 2020 at 12:18:59 UTC, Stefan Koch wrote:
> So we need a type that behaves just like Terror (i.e. is not considered a type by the is expression) but is not an error.
>
> This type is the empty type (Ø).
> It is emptier than void and on the same level as bottom (⊥).
> But Ø cannot be ⊥, because ⊥ can be a valid return type of a function.
> (At least once we have the ⊥ type)

I think you need to find out what you need to prove the semantics of the language to be sound (or which constructs you need to exclude to make it sound). Or just hack together something that isn't exposed to the programmer. Maybe you need to tune the existing language.

So, for instance, if the following was legal "i<j ? true : break". Then break would have the bottom type, never returns anything. So the bottom type has no values. So the conditional expression is of type boolean as the bottom type is included in the type boolean.

A function that is "void f()", on the other can be viewed as returning only one value "void()". So if you allow "i<=j ? (i==j) : f()" the type of the conditional expression would be void|boolean, so it has 3 values I guess. "no value" is exactly one value... :^)

On the other hand, a bottom-value represents situations where you at run time want to represent that a computation is inconclusive. For instance if you spawn two threads to compute f() and g(), and have the expression "f()||g()" then you can continue if either f() or g() succeeds, but you can allow the other one to fail or go into an infinite loop.  If both fail I guess you could assign it a bottom-value.

But you might want to distinguish between "inconclusive" and "contradiction"...

Anyway, it all boils down to the semantics and capabilities of the existing language, if you expose it externally it should not be driven by the compiler implementation.

October 12, 2020
On Monday, 12 October 2020 at 08:13:57 UTC, Ola Fosheim Grøstad wrote:
> other one to fail or go into an infinite loop.  If both fail I guess you could assign it a bottom-value.
>
> But you might want to distinguish between "inconclusive" and "contradiction"...

In case it wasn't clear. A bottom type contains no values, so it cannot contain bottom values...

October 12, 2020
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.

October 12, 2020
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."