After a bit of delay, DIP 1034, "Add a Bottom Type (reboot)", is now in the hands of Walter and Atila for the Formal Assessment. We can expect to have a final decision or some other result by March 4.

You can find the final draft of DIP 1034 here:

https://github.com/dlang/DIPs/blob/1eb2f39bd5b6652a14ef5300062a1234ad00ceb1/DIPs/DIP1034.md

On Wednesday, 3 February 2021 at 09:20:57 UTC, Mike Parker wrote:
> After a bit of delay, DIP 1034, "Add a Bottom Type (reboot)", is now in the hands of Walter and Atila for the Formal Assessment.

Good luck Dennis!

On Wednesday, 3 February 2021 at 09:20:57 UTC, Mike Parker wrote:
> After a bit of delay, DIP 1034, "Add a Bottom Type (reboot)", is now in the hands of Walter and Atila for the Formal Assessment. We can expect to have a final decision or some other result by March 4.
>
> You can find the final draft of DIP 1034 here:
>
> https://github.com/dlang/DIPs/blob/1eb2f39bd5b6652a14ef5300062a1234ad00ceb1/DIPs/DIP1034.md

Is there a short explanation of why this was done and what it enables?

Thanks!

On Wednesday, 3 February 2021 at 18:24:06 UTC, Imperatorn wrote:
> Is there a short explanation of why this was done and what it enables?

It is done to give better semantics to certain things that currently have special cases in the compiler. E.g. the compiler has an internal list of functions that don't return, and `typeof(null)` is a bit of a special case.

This enables:

- Writing your own 'panic' function that the compiler knows terminates control flow (similar to assert(0)) so you don't have to write an unreachable `return` or `break`.
- Throwing exceptions in lambda's: `() => throw new Exception("")`
- Accepting `null` in a template taking a generic pointer `T*`
- Recognizing the empty list `[]` in template functions (currently it is a `void[]`)

On Wed, Feb 03, 2021 at 09:20:57AM +0000, Mike Parker via Digitalmars-d-announce wrote:
> After a bit of delay, DIP 1034, "Add a Bottom Type (reboot)", is now in the hands of Walter and Atila for the Formal Assessment. We can expect to have a final decision or some other result by March 4.
> 
> You can find the final draft of DIP 1034 here:
> 
> https://github.com/dlang/DIPs/blob/1eb2f39bd5b6652a14ef5300062a1234ad00ceb1/DIPs/DIP1034.md

Too late now, but there's a typo in the last code example under section "Flow analysis across functions": the return line should read:

	return x != 0 ? 1024 / x : abort("calculation went awry.");

rather than:

	return x != 0 ? 1024 / x : abort(0, "calculation went awry.");

(extraneous '0' first argument.)


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

On Wednesday, 3 February 2021 at 18:24:06 UTC, Imperatorn wrote:
>
> Is there a short explanation of why this was done and what it enables?
>

Personally I'm excited to see this...

Strangely enough there is a long running 'net wide disagreement on what an assert is or does.

Some regard it as purely a debugging tool used as a programmer aid that is expressly turned on by the programmer, and others (such as myself) regard it as a way of stating, and enforcing the contract, provided by an API.

And as such, people with the latter mindset wish the compiler would warn us if that contract is potentially violated on any path, and conversely, wish the optimizer to act on the information it provides.

By adding it to the type system, it expresses and clarifies the intent of the author of the code, and expresses it in the compilers terms, ie. a type.

In my day job, I have found the only resolution to the disagreement is to create two different facilities with two different names to permit the two groups of humans to get along.

In my day job instead of "assert" we now have "log_If....()" that are opt-in programmer debugging tools and "error_Check...()" that enforce.

On Wednesday, 3 February 2021 at 19:00:20 UTC, Dennis wrote:
> On Wednesday, 3 February 2021 at 18:24:06 UTC, Imperatorn wrote:
>> Is there a short explanation of why this was done and what it enables?
>
> It is done to give better semantics to certain things that currently have special cases in the compiler. E.g. the compiler has an internal list of functions that don't return, and `typeof(null)` is a bit of a special case.
>
> This enables:
>
> - Writing your own 'panic' function that the compiler knows terminates control flow (similar to assert(0)) so you don't have to write an unreachable `return` or `break`.
> - Throwing exceptions in lambda's: `() => throw new Exception("")`
> - Accepting `null` in a template taking a generic pointer `T*`
> - Recognizing the empty list `[]` in template functions (currently it is a `void[]`)

Thanks for the clarification(s)! 🍀