On 07/09/2017 10:10 AM, Steven Schveighoffer wrote:
On 7/9/17 9:16 AM, Andrei Alexandrescu wrote:
I wonder why there's so much attraction to exotic approaches when
encoding "no return" with types has so much established theory and
practice with it. -- Andrei
Your definition of exotic diffe
On 07/09/2017 10:10 AM, Steven Schveighoffer wrote:
I haven't seen another solution other than out { assert(0); }
Your own comment takes it to the recycle bin:
The one disadvantage, is that -release removes contracts. So in this
particular case, the out contract should remain.
That's alread
On Sunday, 9 July 2017 at 14:43:20 UTC, Andrei Alexandrescu wrote:
On 07/09/2017 10:10 AM, Steven Schveighoffer wrote:
I haven't seen another solution other than out { assert(0); }
Your own comment takes it to the recycle bin:
The one disadvantage, is that -release removes contracts. So
in t
On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
It's no more of a hack than leaving assert(0) in release code.
I wouldn't argue that. I do argue it's a hack compared to the principled
solution of a bottom type. -- Andrei
On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:
On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
It's no more of a hack than leaving assert(0) in release code.
I wouldn't argue that. I do argue it's a hack compared to the
principled solution of a bottom type. -- Andrei
On 07/08/2017 02:37 PM, Andrei Alexandrescu wrote:
nice touch of bottom (heh)
Where's D's PC-police now?
intuitive and
just unclean.
I really think this is one case where a dedicated compiler-understood
symbol is not only fully justified but also much cleaner.
That would be my #1 top preference: Your suggestion here, but just make
"NoReturn" (or whatever it'll be called) a speci
On 07/09/2017 06:51 AM, Daniel N wrote:
On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
Has anyone a better idea?
What about
scope(exit) assert(0);
?
void func()
out { assert(0); }
body
{
}
Too indirect and verbose. An
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent - there is no
name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But there are some
issues. What do we do with:
typeof(assert(0))* p;
? What does
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom.
That also leaves the door open for:
alias noreturn = typeof(assert(0));
On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:
On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
It's no more of a hack than leaving assert(0) in release code.
I wouldn't argue that. I do argue it's a hack compared to the
principled solution of a bottom type. -- Andrei
On Sunday, 9 July 2017 at 19:12:45 UTC, Walter Bright wrote:
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent
- there is no name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But
there are some issues.
On Sunday, 9 July 2017 at 19:30:25 UTC, Meta wrote:
I thought some more about the ramifications of having a Bottom
type in D. Having a special type like this interacts badly with
most aspects of D's generic programming capabilities, even on
the simplest level. At the least we would probably hav
On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:
On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
It's no more of a hack than leaving assert(0) in release code.
I wouldn't argue that. I do argue it's a hack compared to the
principled solution of a bottom type.
I would a
On 7/9/2017 12:30 PM, Meta wrote:
[...]
Some great info and links. It's a compelling argument to add a bottom type.
On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
> > It's no more of a hack than leaving assert(0) in release code.
>
> I wouldn't argue that. I do argue it's a hack compared to the
> principled solution o
On 7/9/2017 1:24 PM, Meta wrote:
Another case that we should probably just statically disallow:
alias ImmutableBottom = immutable Bottom; //Ditto for shared, const, etc.
This obviously doesn't make any sense anyway.
Wouldn't `immutable(Bottom)` simply resolve to `Bottom`?
On Sunday, 9 July 2017 at 21:32:31 UTC, Walter Bright wrote:
On 7/9/2017 1:24 PM, Meta wrote:
Another case that we should probably just statically disallow:
alias ImmutableBottom = immutable Bottom; //Ditto for shared,
const, etc.
This obviously doesn't make any sense anyway.
Wouldn't `i
On Sunday, 9 July 2017 at 11:26:27 UTC, Steven Schveighoffer
wrote:
The one disadvantage, is that -release removes contracts. So in
this particular case, the out contract should remain.
Doesn't the compiler know about an out contract even with
-release? I don't understand why -release would
On 07/09/2017 03:12 PM, Walter Bright wrote:
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent - there
is no name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But there
are some issues. What do we do w
On 07/09/2017 03:30 PM, Meta wrote:
alias Bottom = typeof(assert(0)); //for convenience
Speaking of which, I think we shouldn't give it a name, same as
typeof(null). Just keep it typeof(assert(0)). Then wherever it occurs it
is immediately clear it has a special status requiring a second look
On 07/09/2017 06:32 PM, Andrei Alexandrescu wrote:
On 07/09/2017 03:30 PM, Meta wrote:
alias Bottom = typeof(assert(0)); //for convenience
Speaking of which, I think we shouldn't give it a name, same as
typeof(null). Just keep it typeof(assert(0)). Then wherever it occurs it
is immediately c
On Sunday, 9 July 2017 at 22:28:50 UTC, Andrei Alexandrescu wrote:
On 07/09/2017 03:12 PM, Walter Bright wrote:
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is
precedent - there is no name for typeof(null).
I had forgotten about the typeof(nu
On 07/09/2017 07:34 PM, Meta wrote:
On Sunday, 9 July 2017 at 22:28:50 UTC, Andrei Alexandrescu wrote:
On 07/09/2017 03:12 PM, Walter Bright wrote:
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent -
there is no name for typeof(null)
Let's call the bottom type 'B' for the moment, for convenience.
If we think of it like a floating point NaN, then any type construction of B
yields a B:
const(B) -> B
B* -> B
B[] -> B
X[B] -> B
B[X] -> B
Since B cannot have a value, any expression that forms a B can be rep
On 07/09/2017 05:14 PM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
It's no more of a hack than leaving assert(0) in release code.
I wouldn't argue that. I do ar
tion
optimisation
ability to statically reflect upon
ability to implement
Of the approached listed only out{assert(0);} fails the static
reflection check.
Which leaves
1)@noreturn
2)@disable(return)
3)none
1 & 2 are almost functionally identical in their implementation
with 2 requiring
On Sunday, 9 July 2017 at 19:14:37 UTC, Walter Bright wrote:
On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom.
That also leaves the door open for:
alias noreturn = typeof(assert(0));
I would really prefer noreturn (or noreturn_t) to be the
much giving up on arguing in this thread, as it seems people
are really keen to add more bloat to the language in spite of the
obvious bloat-free solution.
But I have to ask, what is the benefit of statically determining that a
function is noreturn? I thought it was just a hint to the compiler
On 2017-07-09 23:14, H. S. Teoh via Digitalmars-d wrote:
I like out{ assert(0); } for pretty much the same reasons as Steven
lists. The biggest pro is that **the language already supports it*.
Contract syntax already is meant to signal intent, and assert(0) signals
"never gets here". You can't f
On Monday, 10 July 2017 at 00:34:54 UTC, Andrei Alexandrescu
wrote:
`typeof(null)` actually has one valid value and doesn't crash
the program when when you try to create an instance of it. We
should not treat this the same as `typeof(null)`.
Agreed (with the mention it's not in contradiction w
On Mon, Jul 10, 2017 at 03:47:35PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
> On 2017-07-09 23:14, H. S. Teoh via Digitalmars-d wrote:
>
> > I like out{ assert(0); } for pretty much the same reasons as Steven
> > lists. The biggest pro is that **the language already supports it*.
> > Contra
rn about what's the difference
between null and bottom); (3) having to implement lots of compiler
changes to handle how this new type interacts with operators and other
types in all possible cases; (4) all of this just for something that (a)
is only rarely used, and (b) could have been easil
On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically determining that a function
is noreturn?
It is useful anywhere dataflow analysis is useful.
FunctionThatDoesnotReturn();
a = b; // error: unreachable code
On 7/10/17 2:38 PM, Walter Bright wrote:
On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically determining that
a function is noreturn?
It is useful anywhere dataflow analysis is useful.
FunctionThatDoesnotReturn();
a = b; // error
On 2017-07-08 12:15, Walter Bright wrote:
C compilers (and by extension C++ compilers) usually have an extension
which allows a function to be marked as one that never returns. The
point of this is it enables improved data flow analysis and better code
being generated.
Noreturn functions crop
On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer
wrote:
On 7/10/17 2:38 PM, Walter Bright wrote:
On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically
determining that a function is noreturn?
It is useful anywhere dataflow
's the difference between null
and bottom); (3) having to implement lots of compiler changes
to handle how this new type interacts with operators and other
types in all possible cases; (4) all of this just for something
that (a) is only rarely used, and (b) could have been easily
im
mizing for?
the case that makes @noreturn worth having is even not optimizing, but
don't adding visual noise at the call site.
case Smth: error("boo");
case Other: ...
oops. i know that `error()` will never return, but compiler doesn't, and
insisting on ad
On 7/10/2017 12:05 PM, Meta wrote:
Currently not. This is either a bug or the compiler's flow analysis is not
robust enough to detect this case.
Flow analysis relies on the function's signature, not its implementation, and
currently the signature contains no information abou
On 7/10/17 3:05 PM, Meta wrote:
On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer wrote:
On 7/10/17 2:38 PM, Walter Bright wrote:
On 7/10/2017 4:00 AM, Steven Schveighoffer wrote:
But I have to ask, what is the benefit of statically determining
that a function is noreturn?
It is
On 7/10/2017 12:02 PM, Jacob Carlborg wrote:
Are those few cases worth optimizing for?
Yes. Not having it makes enforce(), for example, generate poor code.
Am Sat, 8 Jul 2017 03:15:39 -0700
schrieb Walter Bright :
> […]
>
> Having an @noreturn attribute will take care of that:
>
> @noreturn void ThisFunctionExits();
>
> Yes, it's another builtin attribute and attributes are arguably a failure in
> language de
On 2017-07-10 22:00, Walter Bright wrote:
Yes. Not having it makes enforce(), for example, generate poor code.
Not sure I understand. "enforce" will return if the condition is true.
--
/Jacob Carlborg
On 11 July 2017 at 08:46, Jacob Carlborg via Digitalmars-d
wrote:
> On 2017-07-10 22:00, Walter Bright wrote:
>
>> Yes. Not having it makes enforce(), for example, generate poor code.
>
>
> Not sure I understand. "enforce" will return if the condition is true.
>
On 08.07.2017 12:15, Walter Bright wrote:
C compilers (and by extension C++ compilers) usually have an extension
which allows a function to be marked as one that never returns. The
point of this is it enables improved data flow analysis and better code
being generated.
Noreturn functions
On 2017-07-11 09:37, Iain Buclaw via Digitalmars-d wrote:
Right, you can't put noreturn on enforce itself, but you can on the
internal bailOut function called by enforce.
Ah, but I though it would just contain a "throw" for the case the the
condition is false. I see now
On 10.07.2017 18:23, Meta wrote:
...
problems with stuff like typeof(null)* etc. because for the most part
it's just a regular type, unlike Bottom.
Bottom is just a regular type.
On 10.07.2017 04:44, Walter Bright wrote:
Let's call the bottom type 'B' for the moment, for convenience.
If we think of it like a floating point NaN,
It's not. It's an empty type.
then any type construction
of B yields a B:
const(B) -> B
I don't see why to add this special case.
On Tuesday, 11 July 2017 at 08:29:12 UTC, Timon Gehr wrote:
On 10.07.2017 18:23, Meta wrote:
...
problems with stuff like typeof(null)* etc. because for the
most part it's just a regular type, unlike Bottom.
Bottom is just a regular type.
It's a regular type with unusual behaviour due to it
On Monday, 10 July 2017 at 20:00:10 UTC, Steven Schveighoffer
wrote:
This means that you get errors for some instantiations. Which
ironically means you'd need to do something like this:
void foo(alias f)()
{
f();
static if(!isNoreturn!f)
{
auto a = 5;
...// etc.
}
}
T
On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu
wrote:
On 7/8/17 7:07 AM, bachmeier wrote:
On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
Having an @noreturn attribute will take care of that:
@noreturn void ThisFunctionExits();
Why should this be an
On 7/11/17 4:29 AM, Timon Gehr wrote:
On 10.07.2017 18:23, Meta wrote:
...
problems with stuff like typeof(null)* etc. because for the most part
it's just a regular type, unlike Bottom.
Bottom is just a regular type.
Wouldn't the fact that it's a subtype of all other types make it a bit
mo
On 12.07.2017 03:50, Andrei Alexandrescu wrote:
On 7/11/17 4:29 AM, Timon Gehr wrote:
On 10.07.2017 18:23, Meta wrote:
...
problems with stuff like typeof(null)* etc. because for the most part
it's just a regular type, unlike Bottom.
Bottom is just a regular type.
Wouldn't the fact that it
On 11.07.2017 19:27, Meta wrote:
On Tuesday, 11 July 2017 at 08:29:12 UTC, Timon Gehr wrote:
On 10.07.2017 18:23, Meta wrote:
...
problems with stuff like typeof(null)* etc. because for the most part
it's just a regular type, unlike Bottom.
Bottom is just a regular type.
It's a regular typ
On 09.07.2017 23:45, Meta wrote:
...
Another case that we should probably just statically disallow:
... > This obviously doesn't make any sense anyway
... > I don't see a reason for us to ever need to do that
Sorry, but this thinking has no place in type system design. This is
precisely how you
On Wednesday, 12 July 2017 at 09:32:32 UTC, Timon Gehr wrote:
On 09.07.2017 23:45, Meta wrote:
...
Another case that we should probably just statically disallow:
... > This obviously doesn't make any sense anyway
... > I don't see a reason for us to ever need to do that
Sorry, but this thinking
On 07/12/2017 05:32 AM, Timon Gehr wrote:
On 09.07.2017 23:45, Meta wrote:
...
Another case that we should probably just statically disallow:
... > This obviously doesn't make any sense anyway
... > I don't see a reason for us to ever need to do that
Sorry, but this thinking has no place in type
On Wednesday, 12 July 2017 at 14:23:15 UTC, Andrei Alexandrescu
wrote:
On 07/12/2017 05:32 AM, Timon Gehr wrote:
On 09.07.2017 23:45, Meta wrote:
...
Another case that we should probably just statically disallow:
... > This obviously doesn't make any sense anyway
... > I don't see a reason for
On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote:
Anyway, my assertion that Bottom cannot be a subtype of all
other types was actually incorrect: the compiler does not need
to generate code for implicit conversion from Bottom to some
other type, so it can be treated as a subtype.
..
On Saturday, 8 July 2017 at 20:27:11 UTC, H. S. Teoh wrote:
Also, a @noreturn attribute would allow overriding a non-void
class method with a @noreturn one (e.g. the derived class is a
sentinel object that forces an exception / termination upon
calling that method), whereas you can't do
On 7/13/17 2:37 PM, Timon Gehr wrote:
On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote:
Anyway, my assertion that Bottom cannot be a subtype of all other
types was actually incorrect: the compiler does not need to generate
code for implicit conversion from Bottom to some other type,
On Monday, 10 July 2017 at 04:02:59 UTC, Nicholas Wilson wrote:
1)@noreturn
2)@disable(return)
3)none
w.r.t optimisation assuming both 1 & 3 impact DMD equally [...]
I don't think that's true. A Bottom type does not cover all use
cases of @noreturn/@pragma(noreturn
On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote:
Example 1: Polymorphism
class Bird { void fly() { ... } };
class Penguin : Bird { override void fly() @pragma(noreturn) {
assert(0); } };
class EvolvedPenguin : Penguin { override void fly() { ... } };
No matter how you
On 07/14/2017 03:06 PM, Lurker wrote:
On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote:
Example 1: Polymorphism
class Bird { void fly() { ... } };
class Penguin : Bird { override void fly() @pragma(noreturn) {
assert(0); } };
class EvolvedPenguin : Penguin { override void
On 7/13/2017 5:18 PM, Andrei Alexandrescu wrote:
On 7/13/17 2:37 PM, Timon Gehr wrote:
On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote:
Anyway, my assertion that Bottom cannot be a subtype of all other types was
actually incorrect: the compiler does not need to generate code for imp
On 16.07.2017 05:30, Walter Bright wrote:
On 7/13/2017 5:18 PM, Andrei Alexandrescu wrote:
On 7/13/17 2:37 PM, Timon Gehr wrote:
On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote:
Anyway, my assertion that Bottom cannot be a subtype of all other
types was actually incorrect: the comp
On 07/15/2017 11:30 PM, Walter Bright wrote:
On 7/13/2017 5:18 PM, Andrei Alexandrescu wrote:
On 7/13/17 2:37 PM, Timon Gehr wrote:
On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote:
Anyway, my assertion that Bottom cannot be a subtype of all other
types was actually incorrect: the c
On 14.07.2017 17:39, Guillaume Boucher wrote:
On Monday, 10 July 2017 at 04:02:59 UTC, Nicholas Wilson wrote:
1)@noreturn
2)@disable(return)
3)none
w.r.t optimisation assuming both 1 & 3 impact DMD equally [...]
I don't think that's true. A Bottom type does not cover all
On Sunday, 16 July 2017 at 13:03:40 UTC, Timon Gehr wrote:
I don't think that's true. A Bottom type does not cover all
use cases of @noreturn/@pragma(noreturn).
...
I think it does, but it is a significantly more invasive
language change.
The best you can hope for is that any
On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote:
It is therefore most natural to say that Bottom.sizeof == ∞.
True, but size_t.max doesn't have the properties of ∞.
The only sane choice to me seems to be a value of type Bottom,
i.e. is(typeof(Bottom.sizeof) == Bottom).
't comply with a puristic understanding
of inheritance. Maybe that's enough of a reason to not optimize such
use cases, but it still shows that pragma(noreturn) is somehow stronger
than Bottom.
The issue isn't purism, it is type safety. If you create an
EvolvedPenguin, upcast it to a
On 16.07.2017 21:49, Guillaume Boucher wrote:
On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote:
It is therefore most natural to say that Bottom.sizeof == ∞.
True, but size_t.max doesn't have the properties of ∞.
The only sane choice to me seems to be a value of type Bottom, i.e.
is(t
On 07/16/2017 04:15 PM, Timon Gehr wrote:
On 16.07.2017 21:49, Guillaume Boucher wrote:
On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote:
It is therefore most natural to say that Bottom.sizeof == ∞.
True, but size_t.max doesn't have the properties of ∞.
The only sane choice to me see
On 07/13/2017 01:25 PM, Timon Gehr wrote:
On Wednesday, 12 July 2017 at 14:23:15 UTC, Andrei Alexandrescu wrote:
On 07/12/2017 05:32 AM, Timon Gehr wrote:
On 09.07.2017 23:45, Meta wrote:
...
Another case that we should probably just statically disallow:
... > This obviously doesn't make any s
On Sunday, 16 July 2017 at 20:04:25 UTC, Timon Gehr wrote:
The issue isn't purism, it is type safety. If you create an
EvolvedPenguin, upcast it to a Penguin and call the fly method
you get UB. So noreturn would indeed need to enforce that all
overrides are also noreturn.
I see it as
On Sunday, 16 July 2017 at 20:15:11 UTC, Timon Gehr wrote:
On 16.07.2017 21:49, Guillaume Boucher wrote:
On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote:
It is therefore most natural to say that Bottom.sizeof == ∞.
True, but size_t.max doesn't have the properties of ∞.
The only sane
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
An issue is that we already have typeof(null). typeof(null)
and typeof(assert(0))* are two ways to specify almost the same
thing. One question is whether typeof(assert(0))* and
typeof(null) should be the same, or if the former
On Monday, 17 July 2017 at 15:39:30 UTC, Olivier FAURE wrote:
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
An issue is that we already have typeof(null). typeof(null)
and typeof(assert(0))* are two ways to specify almost the
same thing. One question is whether typeof(asse
On 7/17/17 11:39 AM, Olivier FAURE wrote:
I'd really prefer if you avoided the whole `typeof(assert(0))` thing.
First off, it's way too verbose for a simple concept.
Noted, thanks. I won't debate this much but for now I disagree. The "no
return" type has several particular properties that set
used rarely. Therefore it stands to reason
> to consider an attention-seeking notation for it.
[...]
IMO, the observations "used rarely" and "attention-seeking notation" are
better satisfied by an attribute named @noreturn than some strange,
convoluted, arcane invocation like
, etc).
It's also used rarely. Therefore it stands to reason to
consider an attention-seeking notation for it.
[...]
IMO, the observations "used rarely" and "attention-seeking
notation" are better satisfied by an attribute named @noreturn
than some strange, convoluted, arc
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
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
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
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 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 divisi
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
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) &q
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 instan
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 comple
On Monday, 17 July 2017 at 18:10:27 UTC, Andrei Alexandrescu
wrote:
On 7/17/17 11:39 AM, Olivier FAURE wrote:
I'd really prefer if you avoided the whole `typeof(assert(0))`
thing.
First off, it's way too verbose for a simple concept.
Noted, thanks. I won't debate this much but for now I disa
On Monday, 17 July 2017 at 23:01:40 UTC, Walter Bright wrote:
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 =
On Tuesday, 18 July 2017 at 10:17:17 UTC, John Colvin wrote:
how do I store the type "int" in memory?
new Type(TYENUM.Tint32); :o)
On 18.07.2017 12:17, John Colvin wrote:
Better to just not define it.
That's not an option. Bottom is a subtype of all types. It cannot remove
members, even static ones.
On Tuesday, 18 July 2017 at 12:15:06 UTC, Timon Gehr wrote:
On 18.07.2017 12:17, John Colvin wrote:
Better to just not define it.
That's not an option. Bottom is a subtype of all types. It
cannot remove members, even static ones.
Timon, how important is it to actually have bottom ?
... and
'null' of types. We don't really need
another one of those.)
Bottom is the most principled way to encode noreturn (but the D type
system does not have a tradition of being very principled, so
introducing it has a cost that does not really exist the same way in
more orthogonal
On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote:
On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu
via Digitalmars-d wrote:
[...]
[...]
IMO, the observations "used rarely" and "attention-seeking
notation" are better satisfied by an attribute named
On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote:
On 18.07.2017 14:19, Stefan Koch wrote:
[...]
D has a C-inspired first-order type system, so it is not
necessarily crucial to have it in D. (The reason I got involved
in this thread is that it was proposed to add Bottom as a type
t
101 - 200 of 235 matches
Mail list logo
