On 18.07.2017 20:46, Yuxuan Shui wrote:
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 i
On Tuesday, 18 July 2017 at 20:49:56 UTC, Timon Gehr wrote:
On 18.07.2017 20:46, Yuxuan Shui wrote:
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
On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote:
Could you explain why `return foo();` is even legal for a `void
foo() {}`?
Suppose you are writing a template function that forwards:
auto forward(alias fun, T...)(T args) {
return fun(args);
}
It just saves you from having
There is just something fundamentally wrong with:
@noreturn int foo();
returning a value yet not returning. It smacks of "the language designer(s) are
idiots." It winds up complicating things like:
auto x = a ? b : foo();
What is the type of x? @noreturn means a special c
On Tuesday, 18 July 2017 at 21:45:27 UTC, Adam D. Ruppe wrote:
On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote:
Could you explain why `return foo();` is even legal for a
`void foo() {}`?
Suppose you are writing a template function that forwards:
auto forward(alias fun, T...)(T
On 18.07.2017 23:35, Moritz Maxeiner wrote:
Could you explain why `return foo();` is even legal for a `void foo()
{}`?
Because the ad-hoc decision to make void a type that is not really a
type leads to unnecessary friction, and this exceptional rule removes
the friction in one common specia
On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote:
On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote:
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 bys
have, rinse, repeat. (Look at all the different ways to do
type deduction, a horrifying consequence. Or function
overloading, which started with complex special cases, then
changed to partial ordering for special cases.)
There is just something fundamentally wrong with:
@noreturn int foo
On 7/18/2017 5:54 PM, Nicholas Wilson wrote:
There is just something fundamentally wrong with:
@noreturn int foo();
I would understand it to mean that if it were to return, foo would return an int
but it is undefined behaviour for foo to dynamically return.
That's the C++ behavior. I
On Wednesday, 19 July 2017 at 01:52:30 UTC, Walter Bright wrote:
I know how noreturn attributes work - I implemented them
decades ago in DMC and DMC++. They are supported by the DMD
optimizer and back end.
But they are a hack to the type system, and I suggest an
unnecessary one.
It
27;ll just have to disagree.
The backends for DMD, LDC and GDC would not be affected at all by the addition
of a bottom type to the front end, and it would be trivial for the glue code
to add the noreturn attribute for functions that return the bottom type.
Said glue would be unnecessa
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
Perhaps we go the inverse route and define the bottom type as
typeof(*null). Would that simplify matters? There is some good
consistency about it:
null: a pointer to anything. But can't be dereferenced.
*null: well, therefore.
On Wednesday, 19 July 2017 at 10:24:35 UTC, Marc Schütz wrote:
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
Perhaps we go the inverse route and define the bottom type as
typeof(*null). Would that simplify matters? There is some good
consistency about it:
null: a pointer
On 19.07.2017 12:24, Marc Schütz wrote:
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote:
Perhaps we go the inverse route and define the bottom type as
typeof(*null). Would that simplify matters? There is some good
consistency about it:
null: a pointer to anything. But can't
On 19.07.2017 12:35, Stefan Koch wrote:
On Wednesday, 19 July 2017 at 10:24:35 UTC, Marc Schütz wrote:
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote:
Perhaps we go the inverse route and define the bottom type as
typeof(*null). Would that simplify matters? There is some good
On Wednesday, 19 July 2017 at 10:44:22 UTC, Timon Gehr wrote:
No. Bottom is to types as typeof(null) is to class types.
I fear you lost me again :)
as far as I understood your previous explanation, every type is a
subtype of bottom, is that incorrect ?
On Wednesday, 12 July 2017 at 13:22:46 UTC, Meta wrote:
D is not ML or Haskell or Idris. Rust has trod this ground
before us and they saw it prudent to not make ! a first-class
type.
Only to turn around after they realized their mistake:
https://doc.rust-lang.org/stable/book/second-edition/ch
On 19.07.2017 12:59, Stefan Koch wrote:
On Wednesday, 19 July 2017 at 10:44:22 UTC, Timon Gehr wrote:
No. Bottom is to types as typeof(null) is to class types.
I fear you lost me again :)
as far as I understood your previous explanation, every type is a
subtype of bottom, is that incorrect
On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
a value of type bottom can be used to construct a value for any
other type.
AFAIK from type theory, bottom is defined as having no values (so
one can't reason about the relationship of such non-existent
value(s) to values of other
On Wednesday, 19 July 2017 at 11:02:07 UTC, Marc Schütz wrote:
On Wednesday, 12 July 2017 at 13:22:46 UTC, Meta wrote:
D is not ML or Haskell or Idris. Rust has trod this ground
before us and they saw it prudent to not make ! a first-class
type.
Only to turn around after they realized their m
Am Wed, 19 Jul 2017 12:13:40 +
schrieb Moritz Maxeiner :
> On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
> > a value of type bottom can be used to construct a value for any
> > other type.
>
> AFAIK from type theory, bottom is defined as having no values (so
> one can't re
On 19.07.2017 14:13, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
a value of type bottom can be used to construct a value for any other
type.
AFAIK from type theory, bottom is defined as having no values (so one
can't reason about the relationship of su
On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote:
On 19.07.2017 14:13, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
a value of type bottom can be used to construct a value for
any other type.
AFAIK from type theory, bottom is defined as havi
On 19.07.2017 16:47, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote:
On 19.07.2017 14:13, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
a value of type bottom can be used to construct a value for any
other type.
AFAI
On Wednesday, 19 July 2017 at 14:52:28 UTC, Timon Gehr wrote:
On 19.07.2017 16:47, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote:
On 19.07.2017 14:13, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
a value of type bott
On 19.07.2017 17:14, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 14:52:28 UTC, Timon Gehr wrote:
On 19.07.2017 16:47, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote:
On 19.07.2017 14:13, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 11:35:4
On 7/16/2017 6:03 AM, Timon Gehr wrote:
pragma(noreturn) is indeed the simpler solution, as it does not interact with
anything else.
Pragmas are not supposed to change the semantics of the code, they are intended
as directions to the compiler, such as:
* optimization suggestions
* embedding
Timon Gehr wrote:
> [...]
> What I am saying is: in a language with a bottom type, we can create a
> function:
>
> T f(T)(Bottom b){
> return b; // assuming b converts to all types implicitly.
> }
>
> Within the function body, b is a value of type Bottom.
> We use a value of type Bottom to
On 20.07.2017 00:21, Tobias Müller wrote:
Timon Gehr wrote:
[...]
What I am saying is: in a language with a bottom type, we can create a
function:
T f(T)(Bottom b){
return b; // assuming b converts to all types implicitly.
}
Within the function body, b is a value of type Bottom.
We use a
On Wednesday, 19 July 2017 at 10:35:37 UTC, Stefan Koch wrote:
On Wednesday, 19 July 2017 at 10:24:35 UTC, Marc Schütz wrote:
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
Perhaps we go the inverse route and define the bottom type as
typeof(*null). Would that simplify matt
On 07/19/2017 10:32 AM, Timon Gehr wrote:
On 19.07.2017 14:13, Moritz Maxeiner wrote:
On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote:
a value of type bottom can be used to construct a value for any other
type.
AFAIK from type theory, bottom is defined as having no values (so one
I didn't look through all of the replies to this thread to check
that this hasn't been mentioned yet, but TypeScript uses the
'never' return type for functions that never return.
https://www.typescriptlang.org/docs/handbook/basic-types.html#never
The type isn't used for any optimisations, it's
Hello,
Is there any change would could be seeing a noreturn attribute or
way to hide a variable from the -vtls option in D in the near
future?
Sometimes it's desirable to indirectly throw an exception,
especially if there's some work that needs to be done
specifically relating to the
example:
void throwEintr (string funcName) pure noreturn
{
throw new Exception (funcName ~ "() was interrupted by the
OS");
}
void exacerbate (T) (const(T) exc, string msg) pure noreturn
{
throw new T (msg ~ ": " ~ exc.msg);
}
If your patch enforcing that a function ta
If your patch enforcing that a function tagged with noreturn
does not return (so core.stdc.stdlib.exit must be tagged with
noreturn)?
It isn't currently compulsory. Any noreturn function will still
compile without the attribute. If adopted, it would of course be
prudent to make stdlib
201 - 235 of 235 matches
Mail list logo
