On Tuesday, 15 January 2019 at 18:36:30 UTC, Neia Neutuladh wrote:
> Agreed. DIPs should use simple language and aim to use examples whenever possible. Brevity and sounding technical should be explicit non-goals.

+1

IMO, part of the DIP requirements should be that they are written as simply as possible with minimal use of jargon. That's just good sense, though, because people will not be accepting of a DIP that they can't grok.

On 2019-01-15 11:59, Johan Engelen wrote:

> I know we are no longer supposed to discuss the proposal's merits, but...
> 
> The proposal does not describe its merits.

I completley agree.

> 3 - why a new _type_ is needed for describing a property of a function (that's what attributes are for)

Not sure it's even worth an attribute. I'm thinking more a pragma.

-- 
/Jacob Carlborg

On Tuesday, 15 January 2019 at 18:21:25 UTC, Johannes Loher wrote:
> [...]

17.
The DIP does not explicitly state when a function can be declared to return `Tbottom` and when `Tbottom` is inferred as return type.

Is there a difference between
```
Tbottom fun()
{
    return assert(0);
}
```

and

```
Tbottom fun()
{
    assert(0);
}
```
?

Will inference only work if expressions evaluating to `Tbottom` are returned, or is inference for simple things like

```
auto fun()
{
    while(true) {}
}
```

planned? (Obviously this cannot be done in all cases as it is equivalent to the halting problem)

On Tuesday, 15 January 2019 at 18:51:13 UTC, Johannes Loher wrote:
> Will inference only work if expressions evaluating to `Tbottom` are returned, or is inference for simple things like
>
> ```
> auto fun()
> {
>     while(true) {}
> }
> ```
>
> planned? (Obviously this cannot be done in all cases as it is equivalent to the halting problem)

Looks like the compiler already some some kind of analysis to determine if there's a common type for different runtime branches:

import std.stdio;

auto test(int n, float f)
{
    if (n > 0)
        return n;
    else
        return f;
}

auto test2(int n, string s)
{
    if (n > 0)
        return n;
    else
        return s; // Error: mismatched function return type inference of string and int
}

void main()
{
    //Works the same way in CTFE as at runtime
    pragma(msg, test(0, 0.1), " ", typeof(test(0, 0.1)).stringof); // prints "0.1 float"
    writeln(test(0, 0.1), " ", typeof(test(0, 0.1)).stringof);     // ditto

    pragma(msg, test(1, 0.1), " ", typeof(test(1, 0.1)).stringof); // prints "1.0000 float
    writeln(test(1, 0.1), " ", typeof(test(1, 0.1)).stringof);     // ditto
}


This is actually pretty cool, because if the type checker finds that one branch of the function returns Bottom, it can automatically assume that the return type is the type of the other branch, because a function returning T | Bottom can be simplified to a function returning just T. This is because iff the function returns, it must return a value of type T; otherwise, it will not return at all.

On Tuesday, 15 January 2019 at 16:01:13 UTC, Jonathan Marler wrote:
> On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
>> DIP 1017, "Add Bottom Type", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
>>
>> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
>>
>> The current revision of the DIP for this review is located here:
>>
>> https://github.com/dlang/DIPs/blob/4716033a8cbc2ee024bfad8942b2ff6b63521f63/DIPs/DIP1017.md
>>
>> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on January 30 unless I call it off before then.
>>
>> Thanks in advance for your participation.
>
>
> I'd like to point out that this proposal is introducing 2 new semantic features that are related but actually orthogonal.
>
> 1. Allow a functions to be marked as "no return"
> 2. Introduce a "bottom" type defined as typeof(assert(0)).  Any function that returns this type will be marked as "no return".
>
> Other reviewers have asked for why using a "bottom" type is preferable to a function attribute or a special out contract. In regards to the first feature (allow functions to be marked as "no return") they are all "semantically equivalent".  They all provide a way for the control-flow analyzer to know when a function doesn't return and optimize the code surrounding it.
>
> The second feature goes another step further by introducing the "bottom type" into the language.  This introduces new semantics that define how non-returning functions interact with the type system.  Consider the following:
>
> int main(string[] args)
> {
>     return (args.length > 1) || assert(0);
> }
>
> This currently doesn't compile but will with the new "bottom" type.  Note that this example is another demonstration for why these 2 features are orthogonal.
>
> So the question of whether we should use a type/function attribute/contract to mark functions as "no return" is a different question than whether we should be introducing a new bottom type.  The 2 are conflated because if we do introduce a new "bottom" type, then it means we will already have a way to mark a function as "no return".
>
> I would first try to answer whether or not we want the "bottom" type.  If the answer is yes, then we now have a way to mark functions as "no return".  If the answer is no, then we can use a function attribute or special out contract.

To clarify a bit more.

The rationale of the DIP only applies to the first feature which is to come up with some way of marking a functions as "no return". I haven't seen any rationale for the second orthogonal feature which is adding a bottom type to the language.

From what I understand, adding a bottom type to the language allows us to call no-return functions inside expressions.

return a || assert(0);

instead of

if (a)
    return a;
assert(0);

Though I can't come up with a practical use case for this.

What else does the new bottom type give us?  And be sure to distinguish between things that only require "no-return" functions and things that require a bottom type.  If they only require "no-return" functions, then they are not rationale for adding a bottom type.

On Tuesday, 15 January 2019 at 10:08:28 UTC, ixid wrote:
> Sorry to bikeshed but any name other than 'bottom' would be preferable, D may be the butt of the joke so to speak if code is full of this. There are plenty of synonyms.

"never" is used in Rust, i.e., the never type. Scala and a few other languages use Nothing, and Haskell uses Void (not the same as `void` in C-family languages).

On Tuesday, 15 January 2019 at 18:26:55 UTC, Meta wrote:
> On Tuesday, 15 January 2019 at 10:59:40 UTC, Johan Engelen wrote:
>> On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
>>> DIP 1017, "Add Bottom Type", is now ready for Final Review.
>>
>> I know we are no longer supposed to discuss the proposal's merits, but...
>>
>> The proposal does not describe its merits. The only merit listed is being able to specify that a function does not return. The obvious choice is adding a function attribute for that, yet the proposal introduces a new magic type with a whole set of new problems of its own and only has a few lines of text on why an attribute would not cut it.
>
> With all due respect to all involved in this conversation, this DIP should be almost entirely non-controversial, but it is not, because most people posting on this mailing list have a more practical programming background, rather than a theoretical one. When I say that, I am not excluding myself, so please don't interpret it as an insult.

Indeed the whole D community could use more theory input, but the DIP too. However, D is also a practical language and with that constraint come compromises in how to apply theory.
I am indeed out of my depth here, although I know what the bottom type is, but that doesn't mean the DIP shouldn't justify itself much more extensively (with the help of references).

> Let's look at Rust: they have introduced a bottom type, denoted as !, and to my knowledge it was almost entirely without controversy, because that community has a much stronger theoretical focus than D.

Rust is indeed interesting here because, as far as I understand, Rust used to have a bottom type but they removed it because it was causing too much trouble. So we'd need to learn from them why `!` is not a bottom type proper in Rust, and what justification they have for `!` being a not-quite-bottom type and how that applies to D.

>> 4 - D already has a bottom type: `void`, why is a new type needed?
>
> `void` is a unit type, and is not the same as a bottom type.

Yeah, but D's `void` is also not a proper unit type.
D's `void` behaves somewhere in-between the theoretical bottom and unit types.

>> A big addition like this needs a big justification with a solution to a major shortcoming. Not being able to specify a function never returning is just a very minor shortcoming.
>
> I recommend reading up on what the bottom type is, and why it is useful in the context of a language's type system. Not only does it enable certain optimizations, it also has many other useful properties that we can take advantage of.
>
> Stack Overflow can explain it better than me:
>
> https://softwareengineering.stackexchange.com/questions/277197/is-there-a-reason-to-have-a-bottom-type-in-a-programming-language

The link does not really have answers that explain the use of a bottom type in a practical imperative language, beyond that it signifies `noreturn`.
The question we have is whether there is a compelling use for "bottom". I'd like to see a real code use case, besides signifying `noreturn` (trivial).

Btw, you can still throw from such functions (at least that is what the DIP is proposing, e.g. `throw` itself), and the DIP's assertion that you can remove stack unwinding code from blocks calling a `noreturn`/bottom-return function is therefore false.

Being able to specify `noreturn` is definitely useful. Do we really need to complicate the language for it?

In case people are wondering, in LDC you can use `@(ldc.attributes.llvmAttr("noreturn"))`. Ugly, non-standard, yes :/

-Johan

On Tuesday, 15 January 2019 at 22:44:56 UTC, Johan Engelen wrote:
> Being able to specify `noreturn` is definitely useful. Do we really need to complicate the language for it?

IMO, no.

> In case people are wondering, in LDC you can use `@(ldc.attributes.llvmAttr("noreturn"))`. Ugly, non-standard, yes :/

non-standardness can be fixed quite easily

version (LDC)
    enum noreturn = ldc.attributes.llvmAttr("noreturn"));
else version (GDC)
    enum noreturn = gcc.attribute.attribute("noreturn"); // ?
else version (DigitalMars)
    enum noreturn;

I think it fixes the ugliness too.

On Tuesday, 15 January 2019 at 18:26:55 UTC, Meta wrote:
> With all due respect to all involved in this conversation, this DIP should be almost entirely non-controversial, but it is not, because most people posting on this mailing list have a more practical programming background, rather than a theoretical one. When I say that, I am not excluding myself, so please don't interpret it as an insult.

I think this is a very astute observation.

> Let's look at Rust: they have introduced a bottom type, denoted as !, and to my knowledge it was almost entirely without controversy, because that community has a much stronger theoretical focus than D. I know that D is not Rust, but in this instance I feel that we could learn a thing or two rather than grafting on some @noreturn hack (and it *is* a hack that just poorly emulates a bottom type).

To me, bottom is a complex way to signal to the reader and to the optimiser that the function never returns. This task is much more easily done (i.e. the machinery to do so already exists) by an attribute.

> The bottom type is well-understood and has already had all the kinks worked out by academia. It is more a less a free lunch, because somebody else has already done the heavy intellectual lifting for us.

What I still don't see is the _practical benefit_ of a type over an attribute (excluding for the sake of argument the cost of implementation complexity).

>> I would have imagined this proposal to be completely different: describe why having a new bottom type is useful, and then in a small extra paragraph mentioning that this new bottom type can also be used to describe nonreturning functions.
>
> To me, that doesn't make any sense, as the bottom type is THE canonical way to express that a function will not return. It is a type with 0 values, thus, intuitively, there is no possible way a function with a return type of Tbottom could ever possibly return. Thus, it must throw an exception, loop forever, or abort the program.

To me, coming from a C-like background, an attribute is the canonical
way to express that: a function that "noreturn"s, will never returns.

>> A big addition like this needs a big justification with a solution to a major shortcoming. Not being able to specify a function never returning is just a very minor shortcoming.
>
> I recommend reading up on what the bottom type is, and why it is useful in the context of a language's type system. Not only does it enable certain optimizations, it also has many other useful properties that we can take advantage of.
>
> Stack Overflow can explain it better than me:
>
> https://softwareengineering.stackexchange.com/questions/277197/is-there-a-reason-to-have-a-bottom-type-in-a-programming-language


>Now, as for the benefit?
>
>The fact that a function does not return can be useful for:
>
> * optimization: one can prune any code after it (it won't return), there is no need to save the registers (as it won't be necessary to restore them), ...
> * static analysis: it eliminates a number of potential execution paths
> * maintainability: (see static analysis, but by humans)

Those can all be done by an attribute. So it comes down to a cost benefit analysis: the benefits they provide are the same, except the implementation of bottom is going to be much more costly.

On Tuesday, 15 January 2019 at 08:59:07 UTC, Mike Parker wrote:
> DIP 1017, "Add Bottom Type", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment.

What is this new ".alignsize" property ? Is that supposed to be ".alignof" ?