www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I'm glad throw is now an expression

reply deadalnix <deadalnix gmail.com> writes:
So, throw is now an exception. It is true that this is useful, 
for instance, it is now more convenient to throw from a lambda.

This is in fact so convenient that it deserve to break compiler 
explorer, which do not support the feature.

In fact, it is so convenient that it was worth breaking any code 
formater out there (breaking new I maintain one).

In fact so much worth it that it doesn't matter it break syntax 
coloring in numerous text editor. Real programmers use their own 
fork of emacs anyways.

In fact, so extremely convenient that it is worth breaking pretty 
any tools around D. Who need a thriving ecosystem anyways?

In fact, so, so, so convenient that it's worth pushing it out 
with an invalid spec, so that the maintainers of said tools don't 
even have the information they require to fix it.

Listen people, I have nothing against this feature. It's true 
that it is great. But stop breaking everybody's tools all the 
time for random shit with only marginal utility. I need working 
tools way more than throw expressions. I need proper spec way 
more than throw expression. And D needs an ecosystem that is 
growing at some point, which is unlikely to happen breaking 
everybody's shit all the time.

Just bundle all these change in a big upgrade, just do done every 
few years, and be done with it. like any sane language does.

Bonus point: it's buggy 
https://issues.dlang.org/show_bug.cgi?id=23114
May 16 2022
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 16 May 2022 at 15:18:11 UTC, deadalnix wrote:

 This is in fact so convenient that


This post is unhelpful and toxic. By continuing to post in this 
tone you are hurting this community and all the work that 
everyone is doing and has done to get this far.
May 16 2022
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 15:18:11 UTC, deadalnix wrote:

 So, throw is now an exception. It is true that this is useful, 
 for instance, it is now more convenient to throw from a lambda.

 [...]


ThrowExpressions were implemented in libdparse weeks ago. No idea 
if dfmt actually works with them or not but the idea this was 
done with absolutely no concern for the ecosystem is unfair.
May 16 2022
parent WebFreak001 <d.forum webfreak.org> writes:
On Monday, 16 May 2022 at 17:03:08 UTC, max haughton wrote:

 On Monday, 16 May 2022 at 15:18:11 UTC, deadalnix wrote:

 So, throw is now an exception. It is true that this is useful, 
 for instance, it is now more convenient to throw from a lambda.

 [...]


 ThrowExpressions were implemented in libdparse weeks ago. No 
 idea if dfmt actually works with them or not but the idea this 
 was done with absolutely no concern for the ecosystem is unfair.


IMO these small syntax improvements are important to keep the 
language moving and alive. I didn't implement ThrowExpressions in 
libdparse, but I was happy to review it and we got it into 
libdparse promptly end of January.

D-Scanner has a tagged release and will evaluate code properly, 
DCD still needs a new tag but if you compiled from source you 
will already get a newer dsymbol version that supports it even on 
the same tag. dfmt's latest version also includes parsing 
support, but it only operates on tokens so nothing changes there 
really.

I think shortened methods and named arguments are also great 
small improvements like this.
May 17 2022
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 16 May 2022 at 15:18:11 UTC, deadalnix wrote:

 So, throw is now an exception. It is true that this is useful, 
 for instance, it is now more convenient to throw from a lambda.

 This is in fact so convenient that it deserve to break compiler 
 explorer, which do not support the feature.

 In fact, it is so convenient that it was worth breaking any 
 code formater out there (breaking new I maintain one).

 In fact so much worth it that it doesn't matter it break syntax 
 coloring in numerous text editor.


Proper syntax coloring is based on the lexems and shall not 
break. I'd be curious to know which are the text editors that 
cant colorize `throw` anymore.
May 17 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 17 May 2022 at 14:41:24 UTC, Basile B. wrote:

 Proper syntax coloring is based on the lexems and shall not 
 break. I'd be curious to know which are the text editors that 
 cant colorize `throw` anymore.


Proper syntax coloring does way more than this and has been for 
the past 20 years. Highlight invalid constructs, display types, 
expression and alike differently, etc...

Almost any modern text editor will use much more than a lexer. 
Most of them don't support D, for obvious reasons. I use sublime 
text, which has decent support for D. At least as long as you 
don't use throw expressions.
May 17 2022
next sibling parent reply Basile B. <b2.temp fmx.com> writes:
On Tuesday, 17 May 2022 at 21:05:08 UTC, deadalnix wrote:

 On Tuesday, 17 May 2022 at 14:41:24 UTC, Basile B. wrote:

 Proper syntax coloring is based on the lexems and shall not 
 break. I'd be curious to know which are the text editors that 
 cant colorize `throw` anymore.


 Proper syntax coloring does way more than this and has been for 
 the past 20 years. Highlight invalid constructs, display types, 
 expression and alike differently, etc...

 Almost any modern text editor will use much more than a lexer. 
 Most of them don't support D, for obvious reasons. I use 
 sublime text, which has decent support for D.


Yes I see [that ST does 
more](https://github.com/sublimehq/Packages/blob/master/D/D.sublime-syntax). It
has several other issues. 100% of them are caused by the fact that they need to
keep up to date with the grammar. That's a pity, an old unproper syntax
coloring based on the tokens would work just fine.
May 17 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 17 May 2022 at 22:03:38 UTC, Basile B. wrote:

 Yes I see [that ST does 
 more](https://github.com/sublimehq/Packages/blob/master/D/D.sublime-syntax).
It has several other issues. 100% of them are caused by the fact that they need
to keep up to date with the grammar. That's a pity, an old unproper syntax
coloring based on the tokens would work just fine.


No it would not.

You just can't provide the same level of support with lexing you 
can with parsing, this is why we have parsers to begin with.

This attitude is why tooling is so poor for D to begin with.
May 17 2022
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/17/22 8:47 PM, deadalnix wrote:

 On Tuesday, 17 May 2022 at 22:03:38 UTC, Basile B. wrote:

 Yes I see [that ST does 
 more](https://github.com/sublimehq/Packages/blob/master/D/D.sublime-syntax). 
 It has several other issues. 100% of them are caused by the fact that 
 they need to keep up to date with the grammar. That's a pity, an old 
 unproper syntax coloring based on the tokens would work just fine.


 
 No it would not.
 
 You just can't provide the same level of support with lexing you can 
 with parsing, this is why we have parsers to begin with.
 
 This attitude is why tooling is so poor for D to begin with.


libdparse supports the new syntax in question. I'm not sure what more D 
can do. D updated the parser, which is an *official* open-source library 
that implements the parser. It can't make other projects give up their 
NIH parsers.

If someone implemented a D parser in brainfuck, would D have to make 
sure it updated that parser before progressing, just because it's a parser?

-Steve
May 17 2022
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 17 May 2022 at 21:05:08 UTC, deadalnix wrote:

 I use sublime text, which has decent support for D. At least as 
 long as you don't use throw expressions.


There is your problem. Sublime Text likes to be different.

According to the devs, Sublime has its own regex engine optimised 
for speed, and uses custom grammars for syntax highlighting. 
Whenever D evolves, someone needs to patch their grammar up; and 
it’s not the Sublime devs. I did that when the new contract 
format went live. I told the devs that it would be better for D 
to have a syntax highlighter based on one of the maintained 
parsers, but they replied that that would likely never be 
supported. That’s when I stopped using Sublime for D.

I’m currently using Visual Studio Community (not “Code”) which 
uses dmd as a library for the parsing.

— Bastiaan
May 18 2022
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 18 May 2022 at 22:00:26 UTC, Bastiaan Veelo wrote:

 On Tuesday, 17 May 2022 at 21:05:08 UTC, deadalnix wrote:

 I use sublime text, which has decent support for D. At least 
 as long as you don't use throw expressions.


 There is your problem. Sublime Text likes to be different.


I edited the [Editors wiki](https://wiki.dlang.org/Editors) 
accordingly.

— Bastiaan
May 19 2022
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 18 May 2022 at 22:00:26 UTC, Bastiaan Veelo wrote:

 On Tuesday, 17 May 2022 at 21:05:08 UTC, deadalnix wrote:

 I use sublime text, which has decent support for D. At least 
 as long as you don't use throw expressions.


 There is your problem. Sublime Text likes to be different.

 According to the devs, Sublime has its own regex engine 
 optimised for speed, and uses custom grammars for syntax 
 highlighting. Whenever D evolves, someone needs to patch their 
 grammar up; and it’s not the Sublime devs. I did that when the 
 new contract format went live. I told the devs that it would be 
 better for D to have a syntax highlighter based on one of the 
 maintained parsers, but they replied that that would likely 
 never be supported. That’s when I stopped using Sublime for D.

 I’m currently using Visual Studio Community (not “Code”) which 
 uses dmd as a library for the parsing.

 — Bastiaan


It's not a problem, it is how it's done. Pretty no tooling today 
that is geared toward text edition uses the language's reference 
parser, because they need something that recover gracefully on 
invalid syntax rather than giving you an error.

The parser you need for the compiler != the parser you need for 
you editor, code formater, etc...

Consider this, clang and clang-format use different parsers.
May 19 2022
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 19 May 2022 at 14:13:13 UTC, deadalnix wrote:

 On Wednesday, 18 May 2022 at 22:00:26 UTC, Bastiaan Veelo wrote:

 On Tuesday, 17 May 2022 at 21:05:08 UTC, deadalnix wrote:

 I use sublime text, which has decent support for D. At least 
 as long as you don't use throw expressions.


 There is your problem. Sublime Text likes to be different.

 According to the devs, Sublime has its own regex engine 
 optimised for speed, and uses custom grammars for syntax 
 highlighting. Whenever D evolves, someone needs to patch their 
 grammar up;




[…]


 It's not a problem, it is how it's done.


:-) What are you complaining about then? The problem is that 
Sublime Text will never be using any of the officially maintained 
parsers.


 The parser you need for the compiler != the parser you need for 
 you editor, code formater, etc...


Enter dparse.

— Bastiaan.
May 19 2022
parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 19 May 2022 at 14:57:40 UTC, Bastiaan Veelo wrote:

 :-) What are you complaining about then? The problem is that 
 Sublime Text will never be using any of the officially 
 maintained parsers.


Stop being s mart ass, thanks.

D has made 0 progress on tooling for 15 years. If you want to 
make sure this stay this way, keep on with this attitude, it's 
working great.

But keep in mind one thing, the tooling for the alternative was 
trash 15 years ago. Now it is rather good. And this is quickly 
making D an unattractive option.
May 19 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2022 8:18 AM, deadalnix wrote:

 Bonus point: it's buggy https://issues.dlang.org/show_bug.cgi?id=23114


This has nothing in particular to do with throwing expressions. The following 
fails for the same reason:

---
noreturn foo();

int test()
{
     return 1 + foo();
}
---
May 17 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Tuesday, 17 May 2022 at 19:39:14 UTC, Walter Bright wrote:

 On 5/16/2022 8:18 AM, deadalnix wrote:

 Bonus point: it's buggy 
 https://issues.dlang.org/show_bug.cgi?id=23114


 This has nothing in particular to do with throwing expressions. 
 The following fails for the same reason:

 ---
 noreturn foo();

 int test()
 {
     return 1 + foo();
 }
 ---


It also won't be a bug for much longer because I've just updated 
the implicit conversion tables.
May 17 2022
next sibling parent reply kdevel <kdevel vogtner.de> writes:
On Tuesday, 17 May 2022 at 19:44:01 UTC, max haughton wrote:
[...]

 It also won't be a bug for much longer because I've just 
 updated the implicit conversion tables.


This code

```
void main ()
{
    auto q = throw new Exception ("test");
}
```

crashes my dmd v2.100.0 when compiled

```
$ dmd throwexpr.d
Illegal instruction (core dumped)
```

Is this reproducible?
May 17 2022
next sibling parent reply kdevel <kdevel vogtner.de> writes:
On Tuesday, 17 May 2022 at 20:06:35 UTC, kdevel wrote:
[...]

 Is this reproducible?


Issue 23120 - dmd illegal instruction throw expression
May 17 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 18/05/2022 8:50 AM, kdevel wrote:

 On Tuesday, 17 May 2022 at 20:06:35 UTC, kdevel wrote:
 [...]

 Is this reproducible?


 
 Issue 23120 - dmd illegal instruction throw expression


https://issues.dlang.org/show_bug.cgi?id=23120
May 17 2022
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Tuesday, 17 May 2022 at 20:06:35 UTC, kdevel wrote:

 Is this reproducible


Yes, it is.

This is an assertion in the backend (Walter you need to fix these 
they are blocking work on noreturn).

```
dmd: src/dmd/backend/cod4.d:424: Assertion `cast(int)sz > 0' 
failed.
```

However this is a bug with the implementation of noreturn rather 
than throw expressions.
The PR I just raised only adjusts the tables that govern implicit 
conversions to be more aware of noreturn.

I haven't look into this in any detail but the assertion 
triggering here is probably because the frontend is casting the 
noreturn-ing expression to an int. This be a hack to make the 
backend work with noreturn however I'm not familiar with the 
foundation of it's implementation.
May 17 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/17/2022 1:57 PM, max haughton wrote:

 This is an assertion in the backend (Walter you need to fix these they are 
 blocking work on noreturn).


The backend assert is doing its job. Somewhere in the compiler the + should be 
turned into a ,
May 18 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Wednesday, 18 May 2022 at 07:30:15 UTC, Walter Bright wrote:

 On 5/17/2022 1:57 PM, max haughton wrote:

 This is an assertion in the backend (Walter you need to fix 
 these they are blocking work on noreturn).


 The backend assert is doing its job. Somewhere in the compiler 
 the + should be turned into a ,


These is plural unfortunately. There's one particular cod1 ptregs 
assertion that comes up *a lot* but unlike this assertion it 
gives no context other than something broken
May 18 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/18/2022 12:35 AM, max haughton wrote:

 On Wednesday, 18 May 2022 at 07:30:15 UTC, Walter Bright wrote:

 On 5/17/2022 1:57 PM, max haughton wrote:

 This is an assertion in the backend (Walter you need to fix these they are 
 blocking work on noreturn).


 The backend assert is doing its job. Somewhere in the compiler the + should be 
 turned into a ,


 
 These is plural unfortunately. There's one particular cod1 ptregs assertion
that 
 comes up *a lot* but unlike this assertion it gives no context other than 
 something broken


More thinking about this suggests that int+noreturn should be typed as noreturn.
May 18 2022
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 18 May 2022 at 17:35:14 UTC, Walter Bright wrote:

 More thinking about this suggests that int+noreturn should be 
 typed as noreturn.


How so? This makes sense to me:

```d
int divide(int dividend, int divisor)
{
     return divisor == 0
         ? assert(false, "You shall not divide by zero")
         : dividend / divisor;
}
```
May 19 2022
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 19 May 2022 at 09:11:45 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 18 May 2022 at 17:35:14 UTC, Walter Bright wrote:

 More thinking about this suggests that int+noreturn should be 
 typed as noreturn.


 How so? This makes sense to me:

 ```d
 int divide(int dividend, int divisor)
 {
     return divisor == 0
         ? assert(false, "You shall not divide by zero")
         : dividend / divisor;
 }
 ```


`?:` is different from `+` because evaluation of a `?:` 
expression does not require evaluation of all of its operands.

Evaluation of a `+` expression with a `noreturn` operand is 
guaranteed to evaluate the `noreturn` operand, and therefore is 
guaranteed not to terminate, so the `+` expression itself can be 
typed as `noreturn`.
May 19 2022
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 19 May 2022 at 14:16:21 UTC, Paul Backus wrote:

 `?:` is different from `+` because evaluation of a `?:` 
 expression does not require evaluation of all of its operands.

 Evaluation of a `+` expression with a `noreturn` operand is 
 guaranteed to evaluate the `noreturn` operand, and therefore is 
 guaranteed not to terminate, so the `+` expression itself can 
 be typed as `noreturn`.


Ah, so Walter meant addition literally. That does make sense. 
Thanks!
May 19 2022
prev sibling parent kdevel <kdevel vogtner.de> writes:
On Thursday, 19 May 2022 at 09:11:45 UTC, Vladimir Panteleev 
wrote:
[...]

 How so? This makes sense to me:

 ```d
 int divide(int dividend, int divisor)
 {
     return divisor == 0
         ? assert(false, "You shall not divide by zero")
         : dividend / divisor;
 }
 ```


The condition should read

```
    divisor == 0 || dividend == int.min && divisor == -1
```

but that is not the reason why I am posting:

Issue 23126 - wrong result of integer division in presence of 
assert within conditional operator expression
https://issues.dlang.org/show_bug.cgi?id=23126
May 19 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/17/2022 12:44 PM, max haughton wrote:

 It also won't be a bug for much longer because I've just updated the implicit 
 conversion tables.


Quick work!
May 17 2022
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
I actually wanted, and forgot, to file a bug that you can no 
longer override a method with one marked with nothrow.

Since it only adds restrictions and is compatible with a method 
that throws, I think it is a good choice to support like 
contraverience or whichever it is.

Hmm I wonder if that works with const.
May 22 2022
parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 22 May 2022 at 13:56:54 UTC, Jesse Phillips wrote:

 I actually wanted, and forgot, to file a bug that you can no 
 longer override a method with one marked with nothrow.

 Since it only adds restrictions and is compatible with a method 
 that throws, I think it is a good choice to support like 
 contraverience or whichever it is.

 Hmm I wonder if that works with const.


Do you have an example program that demonstrates this bug? The 
following program works for me when compiled with DMD 2.100.0:

```d
class C
{
     void fun() { throw new Exception("oops"); }
}

class D : C
{
     override void fun() nothrow { }
}

void main()
{
     D d = new D;
     C c = new D;
     d.fun(); // ok
     c.fun(); // ok
}
```
May 24 2022