On 7/17/17 2:54 PM, H. S. Teoh via Digitalmars-d wrote:
> I see `typeof(assert(0))` as the same kind of over-engineering of
> something trivially solved and relatively unimportant ("rarely used")
> that has unfortunately plagued C++ design and led C++ to become the mess
> it is today.  It's sad to see D start down the same path...

There is no reason to over-react seeing as the option of adding a name is easy and always available; removing it not so much. This makes taking options in language design highly asymmetrical. Having the type available as an actual expression brings good options on the table because people can return those on unreachable paths etc. -- Andrei

On 7/16/2017 1:15 PM, Timon Gehr wrote:
> In this case, Bottom.sizeof is a value of type Bottom, which must not exist.

T.sizeof is a value of type size_t, not type T.

On 7/16/2017 5:41 AM, Timon Gehr wrote:
> struct S{
>     T x;
>     Bottom everything;
> }
> 
> turns the entire struct into an empty type. It is therefore most natural to say that Bottom.sizeof == ∞. (It's the only choice for which S.sizeof == Bottom.sizeof.)
> 
> Another way to think about it: If something of type A* converts to something of type B* without problems, then one would expect B.sizeof <= A.sizeof. This would imply that Bottom.sizeof >= size_t.max. (Because Bottom* converts to all other pointer types.)
> 
> One small issue is that one needs to avoid overflow for the size of a struct that has multiple fields where one of them is of type Bottom.
> 

But if Bottom does not exist, then S doesn't exist either, and hence the < size relationship has no meaning.

(Reminds me of divide by 0 discussions in calculus class.)

On Mon, Jul 17, 2017 at 06:42:02PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 7/17/17 2:54 PM, H. S. Teoh via Digitalmars-d wrote:
> > I see `typeof(assert(0))` as the same kind of over-engineering of
> > something trivially solved and relatively unimportant ("rarely
> > used") that has unfortunately plagued C++ design and led C++ to
> > become the mess it is today.  It's sad to see D start down the same
> > path...
> 
> There is no reason to over-react seeing as the option of adding a name is easy and always available; removing it not so much. This makes taking options in language design highly asymmetrical. Having the type available as an actual expression brings good options on the table because people can return those on unreachable paths etc. -- Andrei

Actually, I don't really care enough about this issue to want it to be implemented one way or another, as long as there is *some* way to annotate a non-returning function.

But the point is that so much time and effort is being spent on discussing and designing a feature that you have admitted yourself to be "rarely used". As a disinterested bystander I find it somewhat amusing (and sad) to see so much over-engineering of an overly-complex system involving a new basic type in the language, which in turn entails all sorts of corner cases in how it will interact with existing types and constructs, not to mention the implementation complexities that will be involved to pull it off -- all for what?  Just to be able to say "function F doesn't return".  Seems like disproportionate effort for only marginal returns (har har).


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N

On Monday, 17 July 2017 at 23:26:18 UTC, H. S. Teoh wrote:
>
> Actually, I don't really care enough about this issue to want it to be implemented one way or another, as long as there is *some* way to annotate a non-returning function.
>
> But the point is that so much time and effort is being spent on discussing and designing a feature that you have admitted yourself to be "rarely used". As a disinterested bystander I find it somewhat amusing (and sad) to see so much over-engineering of an overly-complex system involving a new basic type in the language, which in turn entails all sorts of corner cases in how it will interact with existing types and constructs, not to mention the implementation complexities that will be involved to pull it off -- all for what?  Just to be able to say "function F doesn't return".  Seems like disproportionate effort for only marginal returns (har har).


I can't agree more. This is textbook procrastination and bike-shedding [1]!
There are dozens of open regressions that could have fixed or great, stalled PRs that could have been reviewed.
In fact if only PRs would be as heartily reviewed as the discussion here, things like the fact that DMD leaks all symbols when imported selectively [2] would have been uncovered earlier.

[1] https://en.wikipedia.org/wiki/Law_of_triviality
[2] https://github.com/dlang/phobos/pull/5584#issuecomment-314910297

On 18.07.2017 01:01, Walter Bright wrote:
> ...
> 
> But if Bottom does not exist, then S doesn't exist either, and hence the < size relationship has no meaning.
> ...

Both Bottom and S exist, but they have no instances.

> (Reminds me of divide by 0 discussions in calculus class.)

The reason division by 0 is left undefined is that instead saying 1/0 = ∞ introduces a new number ∞ that does not play nice with the axioms of a complete ordered field.

The question for instance size is based on the wrong assumption that there is such an instance. It is true none the less that ∞ is the most natural answer to this question, as if you have multiple answers for instance size, you'd take the supremum. Of course, size_t does not contain ∞.

On 7/17/2017 5:06 PM, Seb via Digitalmars-d wrote:
> 
> I can't agree more. This is textbook procrastination and bike-shedding [1]!
> There are dozens of open regressions that could have fixed or great, stalled PRs that could have been reviewed.
> In fact if only PRs would be as heartily reviewed as the discussion here, things like the fact that DMD leaks all symbols when imported selectively [2] would have been uncovered earlier.
> 
> [1] https://en.wikipedia.org/wiki/Law_of_triviality
> [2] https://github.com/dlang/phobos/pull/5584#issuecomment-314910297

Semi-valid, but <insert rational and well written paragraph on the false fungability of time and effort>.

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote:
> IMO, the observations "used rarely" and "attention-seeking notation" are better satisfied by an attribute named @noreturn than some strange, convoluted, arcane invocation like `typeof(assert(0))`.  Because:
>
> (1) "used rarely" means it should be as non-intrusive as possible as far as the language is concerned -- we should not spend a lot of language real estate on something that's rarely used, nor should it be something complicated to implement, and/or introduces tricky corner cases that we're likely to get wrong on first attempt. A @noreturn attribute is non-intrusive -- doesn't interact with anything else in the language, easy to implement -- has no tricky corner cases.
>
> (2) "attention-seeking": an arcane invocation like `typeof(assert(0))` is harder to parse and therefore more likely to invite people to just gloss over it as "incomprehensible gibberish that I'll just ignore unless I have to look further", than catch people's attention.  Whereas an annotation like `@noreturn` is immediately obvious by its very presence, with a name that instantly tells you what it does while it still holds your attention.
>
> I see `typeof(assert(0))` as the same kind of over-engineering of
> something trivially solved and relatively unimportant ("rarely used")
> that has unfortunately plagued C++ design and led C++ to become the mess
> it is today.  It's sad to see D start down the same path...
>
>
> T

(3) LDC and GDC already have an implementation in the form of an attribute so we can just have an AliasSeq of the front end recognised attribute and the one for GDC and LDC (assuming my attributes DIP goes through).

On 7/17/2017 5:13 PM, Timon Gehr wrote:
>> (Reminds me of divide by 0 discussions in calculus class.)
> 
> The reason division by 0 is left undefined is that instead saying 1/0 = ∞ introduces a new number ∞ that does not play nice with the axioms of a complete ordered field.
> 
> The question for instance size is based on the wrong assumption that there is such an instance. It is true none the less that ∞ is the most natural answer to this question, as if you have multiple answers for instance size, you'd take the supremum. Of course, size_t does not contain ∞.

Infinity makes sense for 1/0, but I don't see how that automatically transfers to size_t.

On 18.07.2017 03:06, Walter Bright wrote:
> On 7/17/2017 5:13 PM, Timon Gehr wrote:
>>> (Reminds me of divide by 0 discussions in calculus class.)
>>
>> The reason division by 0 is left undefined is that instead saying 1/0 = ∞ introduces a new number ∞ that does not play nice with the axioms of a complete ordered field.
>>
>> The question for instance size is based on the wrong assumption that there is such an instance. It is true none the less that ∞ is the most natural answer to this question, as if you have multiple answers for instance size, you'd take the supremum. Of course, size_t does not contain ∞.
> 
> Infinity makes sense for 1/0, but I don't see how that automatically transfers to size_t.

It does not. The reasoning is unrelated.