www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] - C++ exceptions are becoming more and more problematic

reply matheus <matheus gmail.com> writes:
Just saw this today:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html

Seems relevant to any System Language like D that features 
Exceptions.

Matheus.
Feb 23 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
I'm kinda in agreement with Herb's proposal for C++ but for D.

Runtime exceptions are expensive and not worth it for _alternative 
results_ which is where we kinda need them and without them things get 
messy...

As a result this is kinda something I would to have in D. The sort of 
thing I was thinking for D:


Support struct based exceptions (value type), passed on stack (and hence 
RC support) as part of the return value of a function.

Add a new attribute ``throws``. It should include types that say what 
will be thrown.

`` throws(Exception)`` would be equivalent to what D functions without 
``nothrow`` are today by default. `` throws()`` would be equivalent to 
``nothrow``.

`` throws(Struct)`` would only allow the Struct to be thrown from a 
function.

A function must either explicitly include or inherit all functions it 
calls throwable types. Unless it catches them (for classes that would 
include parents i.e. Throwable would remove all of them).


I would like to hear other opinions especially Walter's since I don't 
think he has commented on value type exceptions design-wise recently.
Feb 23 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 23 February 2022 at 16:11:45 UTC, rikki cattermole 
wrote:

 `` throws(Exception)`` would be equivalent to what D functions 
 without ``nothrow`` are today by default. `` throws()`` would 
 be equivalent to ``nothrow``.

 `` throws(Struct)`` would only allow the Struct to be thrown 
 from a function.


I'm really against "manually" declaring which exceptions a 
function throws. It will quickly become unmaintainable as people 
will forget which exceptions that are thrown and which are not. 
This means that the compiler must give an error when the 
exception was thrown which wasn't declared. Also warn about 
exceptions not thrown when they are declared so the compiler must 
track the exceptions anyway. Let the compiler do it, that's what 
computers are for. Also let's be conservative with  badging.



 I would like to hear other opinions especially Walter's since I 
 don't think he has commented on value type exceptions 
 design-wise recently.


Walter said that exceptions are on the way out, because of the 
optimization problem which this article also described. He has 
not presented an alternative error handling mechanism.
Feb 23 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/02/2022 5:20 AM, IGotD- wrote:

 I'm really against "manually" declaring which exceptions a function 
 throws. It will quickly become unmaintainable as people will forget 
 which exceptions that are thrown and which are not. This means that the 
 compiler must give an error when the exception was thrown which wasn't 
 declared. Also warn about exceptions not thrown when they are declared 
 so the compiler must track the exceptions anyway. Let the compiler do 
 it, that's what computers are for. Also let's be conservative with 
  badging.


Okay that is easily rectified, we simply allow inheriting from the 
function body, not just called functions ;)

The reason it must support be declared in some form (which is how it is 
also represented in the AST) is due to it being value type. Its like as 
if you put a algebraic type for the return value with your declared 
return value + what can be thrown from it.
Feb 23 2022
parent IGotD- <nise nise.com> writes:
On Wednesday, 23 February 2022 at 16:37:34 UTC, rikki cattermole 
wrote:

 Okay that is easily rectified, we simply allow inheriting from 
 the function body, not just called functions ;)

 The reason it must support be declared in some form (which is 
 how it is also represented in the AST) is due to it being value 
 type. Its like as if you put a algebraic type for the return 
 value with your declared return value + what can be thrown from 
 it.


You have a point there but it kind of depends what the design 
looks like. For example if only one system wide structure is used 
for value exceptions then you don't need to declare it for every 
function.
Feb 23 2022
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 23 February 2022 at 16:20:43 UTC, IGotD- wrote:

 Walter said that exceptions are on the way out, because of the 
 optimization problem which this article also described. He has 
 not presented an alternative error handling mechanism.


Then don't use exceptions for performance reasons. Leave it alone 
for other people who don't care about performance.

-Alex
Feb 23 2022
parent reply IGotD- <nise nise.com> writes:
On Wednesday, 23 February 2022 at 16:52:21 UTC, 12345swordy wrote:

 Then don't use exceptions for performance reasons. Leave it 
 alone for other people who don't care about performance.

 -Alex


I don't exceptions would be removed ever, either from C++ or D 
because that would break a lot of existing C++/D code.

The Herb Sutter exception/return value proposal would live 
alongside with the old exceptions. I suspect that D would do the 
same thing.
Feb 23 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/02/2022 5:59 AM, IGotD- wrote:

 The Herb Sutter exception/return value proposal would live alongside 
 with the old exceptions. I suspect that D would do the same thing.


Yes, with the possibility of having the compiler swap the runtime 
unwinding stuff for value based where possible.

Apart from some situations where you need to be able to store a class 
based exception, I don't see why it couldn't work like this.
Feb 23 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 24, 2022 at 06:02:31AM +1300, rikki cattermole via Digitalmars-d
wrote:

 On 24/02/2022 5:59 AM, IGotD- wrote:

 The Herb Sutter exception/return value proposal would live alongside
 with the old exceptions. I suspect that D would do the same thing.


 
 Yes, with the possibility of having the compiler swap the runtime
 unwinding stuff for value based where possible.
 
 Apart from some situations where you need to be able to store a class
 based exception, I don't see why it couldn't work like this.


If we had by-value exceptions, we can implement the current by-reference
exceptions simply by treating the reference to the allocated exception
as the value to be thrown. I.e.,

	throw new Exception(...);

is equivalent to:

	struct S {
		Exception e;
	}
	Exception e = new Exception(...);
	throwByValue S(e);

So if we implemented by-value exceptions, we don't have to break any
existing code, just treat `throw new SomeException` as syntactic sugar
for some analogue of the above.


T

-- 
PNP = Plug 'N' Pray
Feb 23 2022
parent reply meta <meta gmail.com> writes:
On Wednesday, 23 February 2022 at 17:14:53 UTC, H. S. Teoh wrote:

 On Thu, Feb 24, 2022 at 06:02:31AM +1300, rikki cattermole via 
 Digitalmars-d wrote:

 On 24/02/2022 5:59 AM, IGotD- wrote:

 The Herb Sutter exception/return value proposal would live 
 alongside with the old exceptions. I suspect that D would do 
 the same thing.


 
 Yes, with the possibility of having the compiler swap the 
 runtime unwinding stuff for value based where possible.
 
 Apart from some situations where you need to be able to store 
 a class based exception, I don't see why it couldn't work like 
 this.


 If we had by-value exceptions, we can implement the current 
 by-reference exceptions simply by treating the reference to the 
 allocated exception as the value to be thrown. I.e.,

 	throw new Exception(...);

 is equivalent to:

 	struct S {
 		Exception e;
 	}
 	Exception e = new Exception(...);
 	throwByValue S(e);

 So if we implemented by-value exceptions, we don't have to 
 break any existing code, just treat `throw new SomeException` 
 as syntactic sugar for some analogue of the above.


 T


I am sorry but this feels like "hiding my problems under the 
carpet" type of solution.. it is not very elegant..
Feb 23 2022
parent reply meta <meta gmail.com> writes:
If the fundamentals of the feature are to be rethought / 
redesigned because considered harmful (performance penalty is 
harmful, at least to me), then the users must be prepared and 
educated, so they understand the motive of a potential change, 
and can design APIs with that in mind!


That is how we build future proof libraries, and not "oh, i now 
need to port all that code to a newer language with newer 
constructs" kind of situations..


It's not like the world depends on D, it's a niche market, we 
could, and we should use that to our advantage and move forward, 
without being scared of hurting some people, we can still have a 
long upgrade path, with a solid deprecation model, and some 
static analysis tools in case we still need to depend on a 
library that uses the old model..


C didn't need any of that, reason why it is universally adopted, 
languages depend on it, and is still kicking today!

So the question is why should we even need exceptions? let's 
continue the idea that D is the natural evolution of C, and 
improve on its error handling model with better way to represent 
error codes instead!

My 2 cents..


Sorry for the consecutive posts btw.. :D
Feb 23 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 24/02/2022 1:34 PM, meta wrote:

 If the fundamentals of the feature are to be rethought / redesigned 
 because considered harmful (performance penalty is harmful, at least to 
 me), then the users must be prepared and educated, so they understand 
 the motive of a potential change, and can design APIs with that in mind!


I am not proposing that we remove or modify runtime exceptions that we 
currently have. They serve a purpose even if I don't use them.

It can be reimplemented under the hood, but this is something that no 
user should ever notice. So there isn't any education required unless 
you want to throw them pretty much.
Feb 23 2022
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 23, 2022 at 04:20:43PM +0000, IGotD- via Digitalmars-d wrote:

 On Wednesday, 23 February 2022 at 16:11:45 UTC, rikki cattermole wrote:

 
 `` throws(Exception)`` would be equivalent to what D functions without
 ``nothrow`` are today by default. `` throws()`` would be equivalent to
 ``nothrow``.
 
 `` throws(Struct)`` would only allow the Struct to be thrown from a
 function.
 


 
 I'm really against "manually" declaring which exceptions a function
 throws.  It will quickly become unmaintainable as people will forget
 which exceptions that are thrown and which are not.


Yeah, this is just another variation on Java's checked exceptions, which
experience has proven is not worth the trouble, because people find it
too cumbersome and either don't use it or just slap on boilerplate like
`throws(Exception)` just to make the compiler shut up, which defeats the
whole purpose.


[...]

 I would like to hear other opinions especially Walter's since I
 don't think he has commented on value type exceptions design-wise
 recently.


 
 Walter said that exceptions are on the way out, because of the
 optimization problem which this article also described. He has not
 presented an alternative error handling mechanism.


The problem described in this article doesn't seem to be the same
problem as Walter mentioned in the past. The problem here is primarily
caused by contention on a global mutex used by the stack unwinder; I
don't know if the D implementation actually has this problem.

The problem Walter mentioned in the past is more with how it interacts
with the optimizer: once a set of functions may throw, the optimizer can
no longer assume linear control flow through the code that calls these
functions, so it cannot apply optimizations like reordering code, and
data flow analysis becomes a lot hairier.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.
Feb 23 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 24/02/2022 6:02 AM, H. S. Teoh wrote:

 Yeah, this is just another variation on Java's checked exceptions, which
 experience has proven is not worth the trouble, because people find it
 too cumbersome and either don't use it or just slap on boilerplate like
 `throws(Exception)` just to make the compiler shut up, which defeats the
 whole purpose.


Not quite.

You don't have to write  throws in the majority. It would be inferred 
automatically (only function pointers).

How it is represented in the AST and how the di generator will generate 
code should be simple like this. But most developers shouldn't have to 
touch the attribute even for the main function.

So in practice this should be more similar to our experience with 
nothrow and  safe/trusted/system rather than Java's.
Feb 23 2022
prev sibling parent reply meta <meta gmail.com> writes:
 Support struct based exceptions (value type), passed on stack 
 (and hence RC support) as part of the return value of a 
 function.



Who will allocates that (the RC part)?

I personally disagree with the idea of exceptions altogether..


The answer is in solutions like in Zig/Go, errors, multiple 
return values, if changing the way error handling works in D, 
better make it good, for good!

There is no reason to be stuck with exceptions..

I moved away from them completly in C++, i wish i could do the 
same with D..
Feb 23 2022
next sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 24 February 2022 at 00:19:44 UTC, meta wrote:

 Who will allocates that (the RC part)?

 I personally disagree with the idea of exceptions altogether..


 The answer is in solutions like in Zig/Go, errors, multiple 
 return values, if changing the way error handling works in D, 
 better make it good, for good!

 There is no reason to be stuck with exceptions..


There are reasons to be stuck with exceptions. Go is a no go, due 
to constant if else error checking it forces user to do. 
Exceptions perfectly represent exceptional cases that can be 
handled if caller wants to. Littering every method with tuples as 
return values and method calls with if checking is even worse 
than performance costs of how currently exceptions are 
implemented.

The point is, not all code is required to be performant, some of 
it, can use exceptions for code and logic readability at cost of 
performance downgrade.
Feb 23 2022
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 24 February 2022 at 00:51:31 UTC, Alexandru Ermicioi 
wrote:

 Go is a no go, due to constant if else error checking it forces 
 user to do.


Personally I actually kind of prefer how Go handles things. I 
know people absolutely love to shit on the `if err != nil` spam, 
but to me it makes control flow really simple to follow.

I think if we were to have value-type exceptions in D, the most 
important thing would be syntax.

Some very not thought out and wacky ideas to try and spark 
someone else to make an actually good idea:

```d
// Running a series of functions, and only caring if they 
returned an exception afterwards
// (this particular syntax would obviously introduce ambiguous 
syntax if used, but it's an example)

alias ConvException = ValueException!"conv";

// In this example, functions can only return a single type of 
exception
int toInt(string str) throw(ConvException)
{
    if(isNumber(str))
       return toNumber(str);
    throw typeof(throw)("str is not a number");
}

int a;
int b;

// Even if an exception is thrown, things are still ran until the 
end
// only then are the catch statements ran.
try(ConvException ex) {
    a = toInt("123") catch(ex);
    b = (toInt("345") catch(ex) + toInt("abc") catch(ex));
}
catch(ConvException ex)
{
     writeln(ex.msg);
     return -1;
}
```

On a similar vein, if we have that sort of `catch expression` 
shown above, we could possibly make our own version of `if err != 
nil` spam look even worse :D!

```d
ConvException ex;

if(toInt("123") catch(ex) + toInt("abc") catch(ex) && ex.isError)
{
     writeln(ex.msg);
     return -1;
}
```

On the topic of function chaining, let me introduce you to this 
beauty that my head just came up with.

```d
Exception1 a;
Exception2 b;
Exception3 c;

// " a" means "capture any exception into `a` and go straight to 
the catch block if something was thrown.

try someValue.func1() a.func2() b.func3 c
catch(a){}
catch(b){}
catch(c){}
```

(Don't ever let me design my own language).

But the point is, if we want to avoid Go's if-else spam, we need 
some other weird syntax to sugar on top of things.
Feb 23 2022
next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 24 February 2022 at 03:42:42 UTC, SealabJaster wrote:

 // (this particular syntax would obviously introduce ambiguous 
 syntax if used, but it's an example)


Whoops, meant to remove that part. The original version of that 
example was even more amazing/ridiculous :D
Feb 23 2022
prev sibling next sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 24 February 2022 at 03:42:42 UTC, SealabJaster wrote:

 On Thursday, 24 February 2022 at 00:51:31 UTC, Alexandru 
 Ermicioi wrote:

 Go is a no go, due to constant if else error checking it 
 forces user to do.


 Personally I actually kind of prefer how Go handles things. I 
 know people absolutely love to shit on the `if err != nil` 
 spam, but to me it makes control flow really simple to follow.


It may be simpler, but it is also way noisier than try catch & 
throw, and way more easier to trip over it and have a bug.


 I think if we were to have value-type exceptions in D, the most 
 important thing would be syntax.

 Some very not thought out and wacky ideas to try and spark 
 someone else to make an actually good idea:

 ```d
 // Running a series of functions, and only caring if they 
 returned an exception afterwards
 // (this particular syntax would obviously introduce ambiguous 
 syntax if used, but it's an example)

 alias ConvException = ValueException!"conv";

 // In this example, functions can only return a single type of 
 exception
 int toInt(string str) throw(ConvException)
 {
    if(isNumber(str))
       return toNumber(str);
    throw typeof(throw)("str is not a number");
 }

 int a;
 int b;

 // Even if an exception is thrown, things are still ran until 
 the end
 // only then are the catch statements ran.
 try(ConvException ex) {
    a = toInt("123") catch(ex);
    b = (toInt("345") catch(ex) + toInt("abc") catch(ex));
 }
 catch(ConvException ex)
 {
     writeln(ex.msg);
     return -1;
 }
 ```

 On a similar vein, if we have that sort of `catch expression` 
 shown above, we could possibly make our own version of `if err 
 != nil` spam look even worse :D!

 ```d
 ConvException ex;

 if(toInt("123") catch(ex) + toInt("abc") catch(ex) && 
 ex.isError)
 {
     writeln(ex.msg);
     return -1;
 }
 ```

 On the topic of function chaining, let me introduce you to this 
 beauty that my head just came up with.

 ```d
 Exception1 a;
 Exception2 b;
 Exception3 c;

 // " a" means "capture any exception into `a` and go straight 
 to the catch block if something was thrown.

 try someValue.func1() a.func2() b.func3 c
 catch(a){}
 catch(b){}
 catch(c){}
 ```

 (Don't ever let me design my own language).

 But the point is, if we want to avoid Go's if-else spam, we 
 need some other weird syntax to sugar on top of things.


Just why do we need new syntax? Can't we have it in terms of 
existing one?

Also proposed value exceptions look terribly similar to java 
checked exceptions, which are avoided in java world due to 
spamming issue it causes when trying to propagate them across 
call chain up to location where it is caught. Having them in D is 
like importing a bad feature from java, at least in current 
version they are suggested.
Feb 24 2022
prev sibling parent forkit <forkit gmail.com> writes:
On Thursday, 24 February 2022 at 03:42:42 UTC, SealabJaster wrote:

 ...
 On a similar vein, if we have that sort of `catch expression` 
 shown above, we could possibly make our own version of `if err 
 != nil` spam look even worse :D!

 ...

 if(toInt("123") catch(ex) + toInt("abc") catch(ex) && 
 ex.isError)
 {
     writeln(ex.msg);
     return -1;
 }
 ```

 But the point is, if we want to avoid Go's if-else spam, we 
 need some other weird syntax to sugar on top of things.


Hey...let's just go crazy, and borrow some bew syntax from the 
.net team (bang..bang !!)

// don't ask me what this would do... I don't care.
if( toInt("123")!! + toInt("abc")!!)
{
    writeln(ex.msg);
    return -1;
}

Seriously, when will this obsesssion with constantly changing 
languages..stop!

D... plz learn the lessons from the silly .net team... I no 


https://devblogs.microsoft.com/dotnet/early-peek-at-csharp-11-features/
Mar 04 2022
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
I did a double take and thought I had somehow replied to this 
thread and forgot about it. This forum ain't big enough for the 
two of us 😛
Feb 23 2022
parent reply meta <meta gmail.com> writes:
On Thursday, 24 February 2022 at 00:52:56 UTC, Meta wrote:

 I did a double take and thought I had somehow replied to this 
 thread and forgot about it. This forum ain't big enough for the 
 two of us 😛


sorry :D



 There are reasons to be stuck with exceptions. Go is a no go, 
 due to constant if else error checking it forces user to do.


I agree, but it is getting better! Also the idea is to not mimic 
them, but to learn from them instead and move forward..
Feb 23 2022
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 24 February 2022 at 01:04:47 UTC, meta wrote:

 There are reasons to be stuck with exceptions. Go is a no go, 
 due to constant if else error checking it forces user to do.


 I agree, but it is getting better! Also the idea is to not 
 mimic them, but to learn from them instead and move forward..


Sure, D should be taking best parts from other languages and 
improve them. It's just, that having no exceptions, and no 
alternative as good as them or better, might not be the best 
idea. I personally don't care how exceptions are implemented 
under the hood as long as they   do their job well enough for 
staple source code (non-perf chunks of the code). Performance 
sensitive code should just use more performant alternatives to 
exceptions.

Imho, nicest option would be to provide ability to choose what 
implementation of exception mechanism a function uses. Then for 
function expected to fail often, you could choose to propagate 
the exception through as part of return argument, or any other 
mechanism that is performing better at cost of non-exception path.
Feb 23 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/23/2022 4:19 PM, meta wrote:

 I moved away from them completly in C++, i wish i could do the same with D..


dmd does not use exceptions at all.

One of the requirements I proposed for Phobos2 was for it to not use exceptions.
Feb 23 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/02/2022 6:05 PM, Walter Bright wrote:

 One of the requirements I proposed for Phobos2 was for it to not use 
 exceptions.


This is the sort of code we are going to end up with without a solution 
like value type exceptions. Explicit error types and returns ala 
 mustuse are not better than runtime exceptions, they are much worse for 
readability.

We need a better solution than this.

             if (isF || isLF) {
                 auto destinationr = destination.get!float("r"), 
destinationg = destination.get!float("g"),
                     destinationb = destination.get!float("b");
                 assert(destinationr, destinationr.error.toString());
                 assert(destinationg, destinationg.error.toString());
                 assert(destinationb, destinationb.error.toString());

                 destinationr = sourceR;
                 destinationg = sourceG;
                 destinationb = sourceB;
             } else if (isI8 || isLI8) {
                 auto destinationr = destination.get!ubyte("r"), 
destinationg = destination.get!ubyte("g"),
                     destinationb = destination.get!ubyte("b");
                 assert(destinationr, destinationr.error.toString());
                 assert(destinationg, destinationg.error.toString());
                 assert(destinationb, destinationb.error.toString());

                 destinationr = cast(ubyte)(sourceR * 255f);
                 destinationg = cast(ubyte)(sourceG * 255f);
                 destinationb = cast(ubyte)(sourceB * 255f);
             } else if (isI16 || isLI16) {
                 auto destinationr = destination.get!ushort("r"), 
destinationg = destination.get!ushort("g"),
                     destinationb = destination.get!ushort("b");
                 assert(destinationr, destinationr.error.toString());
                 assert(destinationg, destinationg.error.toString());
                 assert(destinationb, destinationb.error.toString());

                 destinationr = cast(ushort)(sourceR * 65535f);
                 destinationg = cast(ushort)(sourceG * 65535f);
                 destinationb = cast(ushort)(sourceB * 65535f);
             } else
                 assert(0);
Feb 23 2022
next sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 24 February 2022 at 07:23:34 UTC, rikki cattermole 
wrote:

 On 24/02/2022 6:05 PM, Walter Bright wrote:

 One of the requirements I proposed for Phobos2 was for it to 
 not use exceptions.


 This is the sort of code we are going to end up with without a 
 solution like value type exceptions. Explicit error types and 
 returns ala  mustuse are not better than runtime exceptions, 
 they are much worse for readability.

 We need a better solution than this.


So why not have this implemented as underlying mechanism for 
existing try catch syntax, with option to choose which one to use?

If done so, there shouldn't be any usability downgrade, when 
selecting either existing or new exception mechanism, only 
distribution of performance overhead will change.
Feb 24 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 24/02/2022 9:42 PM, Alexandru Ermicioi wrote:

 So why not have this implemented as underlying mechanism for existing 
 try catch syntax, with option to choose which one to use?
 
 If done so, there shouldn't be any usability downgrade, when selecting 
 either existing or new exception mechanism, only distribution of 
 performance overhead will change.


My concern is that there will be situations which no one can predict; 
exceptions are very hairy (after all, they can go up the chain of 
functions not written in D).

This is why I'm not suggesting that we should replace exception handling 
in the general case. Only where the compiler can see that it can be done 
(plus this can be improved over time).
Feb 24 2022
parent reply IGotD- <nise nise.com> writes:
On Thursday, 24 February 2022 at 11:07:31 UTC, rikki cattermole 
wrote:

 My concern is that there will be situations which no one can 
 predict; exceptions are very hairy (after all, they can go up 
 the chain of functions not written in D).

 This is why I'm not suggesting that we should replace exception 
 handling in the general case. Only where the compiler can see 
 that it can be done (plus this can be improved over time).


I think that exceptions work kind of well in a code cleanness 
kind of way. The proposal from Herb Sutter looks like exceptions 
but it is return values under the hood.

D also has the ingenious scope guards (scope(exit) and such) 
which work very well with exceptions. It would be bad if this 
would be thrown away with a new error handling mechanism. 
Therefore I think return values should also have the exception 
syntax.
Feb 24 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/02/2022 12:22 AM, IGotD- wrote:

 D also has the ingenious scope guards (scope(exit) and such) which work 
 very well with exceptions. It would be bad if this would be thrown away 
 with a new error handling mechanism. Therefore I think return values 
 should also have the exception syntax.


Agreed, I didn't write it in my proposal earlier because nothing syntax 
wise would change for how you would use it.

The only difference is the  throws attribute as far as users are 
concerned and that has benefits by itself.
Feb 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/23/2022 11:23 PM, rikki cattermole wrote:

 
 On 24/02/2022 6:05 PM, Walter Bright wrote:

 One of the requirements I proposed for Phobos2 was for it to not use
exceptions.


 
 This is the sort of code we are going to end up with without a solution like 
 value type exceptions. Explicit error types and returns ala  mustuse are not 
 better than runtime exceptions, they are much worse for readability.


I agree, which makes this a challenge.

One solution is to design the return value so that failure is a valid part of 
the type. For example, searching for X can return an empty result, rather than
a 
special "not found" error.

Another solution is to redesign the problem. For example, currently Phobos 
throws on an invalid Unicode character. A better way is to treat such as a 
"replacement character".
Feb 24 2022
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 24, 2022 at 11:14:39AM -0800, Walter Bright via Digitalmars-d wrote:

 On 2/23/2022 11:23 PM, rikki cattermole wrote:

 
 On 24/02/2022 6:05 PM, Walter Bright wrote:

 One of the requirements I proposed for Phobos2 was for it to not
 use exceptions.


 
 This is the sort of code we are going to end up with without a
 solution like value type exceptions. Explicit error types and
 returns ala  mustuse are not better than runtime exceptions, they
 are much worse for readability.


 
 I agree, which makes this a challenge.
 
 One solution is to design the return value so that failure is a valid
 part of the type. For example, searching for X can return an empty
 result, rather than a special "not found" error.


[...]

The problem with replacing exceptions with return codes is that it
requires writing tons of boilerplate to handle error codes. I work with
C at work every day, and eventually every function starts looking like
this:

	int some_func(some_type_t *some_args) {
		int ret = SOME_FUNC_ERR;

		if ((ret = do_something(...)) != DO_SOMETHING_OK)
			goto EXIT;

		if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
			goto EXIT;

		if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
			goto EXIT;

		// ... ad nauseaum

		ret = SOME_FUNC_OK;
	EXIT:
		return ret;
	}

Every single function call must be wrapped with `if ((ret = blah(bleh))
== bluh)` boilerplate, and every developer on the team inevitably
reinvents their own system of error codes, so you have 1001 different
representations of success and failure, and woe to you when you mix up
one for the other because you'd have silently introduced a subtle bug.

And of course, given the painful amounts of boilerplate involved, people
tend to get lazy so error codes are not checked, or don't get propagated
correctly, etc..

Not to mention the proliferation of thrice-reinvented gratuitously
incompatible lists of error codes across every module, and sometimes
every function. Once you go past 1 or 2 levels in the call graph, the
fine distinctions between these error codes get lost in translation,
with the inevitable result that nobody uses any of the error codes
except for "OK" and "INTERNAL_ERROR".  Every single possible failure in
a complex subsystem of 26-level deep function calls eventually collapses
onto a generic, useless "INTERNAL_ERROR", and good luck to the poor fool
who has to debug where in the 50 or so files the problem is when the
customer reports that the application said "internal error".


This is NOT where I want D to go.  Getting rid of exceptions is a
non-solution, we're just going back to the bad ole days of manual error
checking, gratuitous boilerplate, and incentivizing programmers to
ignore / shove aside errors as much as possible 'cos error handling just
Gets In The Way(tm).

What we should be doing instead is, free ourselves from the needless
constraints of C++ exception handling, and implement a better mechanism
for throwing exceptions. Leave C++ interop at the C++/D boundary;
extern(D) code ought to be able to throw away libunwind and use a much
more efficient implementation of exceptions than C++ does.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and
now it's killing me! -- Schoolboy
Feb 24 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2022 12:01 PM, H. S. Teoh wrote:

 The problem with replacing exceptions with return codes is that it
 requires writing tons of boilerplate to handle error codes.


I specifically said not using return codes, and gave examples.
Feb 24 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 24, 2022 at 02:42:14PM -0800, Walter Bright via Digitalmars-d wrote:

 On 2/24/2022 12:01 PM, H. S. Teoh wrote:

 The problem with replacing exceptions with return codes is that it
 requires writing tons of boilerplate to handle error codes.


 
 I specifically said not using return codes, and gave examples.


It amounts to the same thing: the caller must explicitly handle all
error conditions. This is cumbersome and incentivises people to ignore
error conditions or just sweep it under the rug.  And often, the caller
simply isn't in the position to decide how to handle the error condition
(for example, whether a particular error condition is fatal or not
depends on contextual information that's only available further up the
call stack).

More specifically: making failure a valid part of your return type
requires that your callers explicitly check for this failure. It's just
a paraphrasis of `if ((ret = func(...)) != OK) goto EXIT;`. Explicit
checking is a good idea in some cases, but in other cases introduces
unacceptable amounts of boilerplate, such as when every function call in
a long list of function calls must be wrapped around `if (error) goto
EXIT;` boilerplate.

Also, redesigning the problem like using the replacement character on
invalid UTF-8 does not always make sense.  Sometimes you *want* your
code to abort upon failure rather than silently substitute a nonce value
in your data. E.g., if you're deep inside some parsing function and
encounter a UTF-8 encoding problem, you do not want it to just insert
some replacement data that isn't part of the input stream; you want it
to bail out and abort the entire operation with a proper error message.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before
which you fail to deliver after.
Feb 24 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2022 3:44 PM, H. S. Teoh wrote:

 On Thu, Feb 24, 2022 at 02:42:14PM -0800, Walter Bright via Digitalmars-d
wrote:

 On 2/24/2022 12:01 PM, H. S. Teoh wrote:

 The problem with replacing exceptions with return codes is that it
 requires writing tons of boilerplate to handle error codes.


 I specifically said not using return codes, and gave examples.


 
 It amounts to the same thing: the caller must explicitly handle all
 error conditions.


Not if you do it right. It's a challenge, I know.

The NaN result from floating point errors is an example. You can continue using 
the value without checking - the error nicely propagates with no effort or cost.



 Also, redesigning the problem like using the replacement character on
 invalid UTF-8 does not always make sense.  Sometimes you *want* your
 code to abort upon failure rather than silently substitute a nonce value
 in your data. E.g., if you're deep inside some parsing function and
 encounter a UTF-8 encoding problem, you do not want it to just insert
 some replacement data that isn't part of the input stream; you want it
 to bail out and abort the entire operation with a proper error message.


Interestingly, it seems one almost never wants to do this. For those that do, 
running a validator over your string first is a reasonable solution.

We do another technique inside D. The error is printed when the error is found, 
then a special AST error node is created, which is just ignored by everything 
else. It works out reasonably well.
Feb 24 2022
prev sibling next sibling parent reply meta <meta gmail.com> writes:
On Thursday, 24 February 2022 at 20:01:20 UTC, H. S. Teoh wrote:

 On Thu, Feb 24, 2022 at 11:14:39AM -0800, Walter Bright via 
 Digitalmars-d wrote:

 On 2/23/2022 11:23 PM, rikki cattermole wrote:

 
 On 24/02/2022 6:05 PM, Walter Bright wrote:

 One of the requirements I proposed for Phobos2 was for it 
 to not use exceptions.


 
 This is the sort of code we are going to end up with without 
 a solution like value type exceptions. Explicit error types 
 and returns ala  mustuse are not better than runtime 
 exceptions, they are much worse for readability.


 
 I agree, which makes this a challenge.
 
 One solution is to design the return value so that failure is 
 a valid part of the type. For example, searching for X can 
 return an empty result, rather than a special "not found" 
 error.


 [...]

 The problem with replacing exceptions with return codes is that 
 it requires writing tons of boilerplate to handle error codes. 
 I work with C at work every day, and eventually every function 
 starts looking like this:

 	int some_func(some_type_t *some_args) {
 		int ret = SOME_FUNC_ERR;

 		if ((ret = do_something(...)) != DO_SOMETHING_OK)
 			goto EXIT;

 		if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
 			goto EXIT;

 		if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
 			goto EXIT;

 		// ... ad nauseaum

 		ret = SOME_FUNC_OK;
 	EXIT:
 		return ret;
 	}

 Every single function call must be wrapped with `if ((ret = 
 blah(bleh)) == bluh)` boilerplate, and every developer on the 
 team inevitably reinvents their own system of error codes, so 
 you have 1001 different representations of success and failure, 
 and woe to you when you mix up one for the other because you'd 
 have silently introduced a subtle bug.

 And of course, given the painful amounts of boilerplate 
 involved, people tend to get lazy so error codes are not 
 checked, or don't get propagated correctly, etc..

 Not to mention the proliferation of thrice-reinvented 
 gratuitously incompatible lists of error codes across every 
 module, and sometimes every function. Once you go past 1 or 2 
 levels in the call graph, the fine distinctions between these 
 error codes get lost in translation, with the inevitable result 
 that nobody uses any of the error codes except for "OK" and 
 "INTERNAL_ERROR".  Every single possible failure in a complex 
 subsystem of 26-level deep function calls eventually collapses 
 onto a generic, useless "INTERNAL_ERROR", and good luck to the 
 poor fool who has to debug where in the 50 or so files the 
 problem is when the customer reports that the application said 
 "internal error".


 This is NOT where I want D to go.  Getting rid of exceptions is 
 a non-solution, we're just going back to the bad ole days of 
 manual error checking, gratuitous boilerplate, and 
 incentivizing programmers to ignore / shove aside errors as 
 much as possible 'cos error handling just Gets In The Way(tm).

 What we should be doing instead is, free ourselves from the 
 needless constraints of C++ exception handling, and implement a 
 better mechanism for throwing exceptions. Leave C++ interop at 
 the C++/D boundary; extern(D) code ought to be able to throw 
 away libunwind and use a much more efficient implementation of 
 exceptions than C++ does.


 T


Nobody said to verbatim copy what C does, I personally explicitly 
said to take that idea and evolve it, just like the newer modern 
languages are properly doing (Go, Zig, Rust, Odin)

Tagged Unions, Multiple return type, enum/type inference, 
constructs to bubble up things etc.. we must move forward!

I suspect in the near future, exception handling will be seen as 
very bad practice, if not already, we must prepare..

We no longer live in an era with single cores!
Feb 24 2022
next sibling parent forkit <forkit gmail.com> writes:
On Thursday, 24 February 2022 at 23:59:56 UTC, meta wrote:

 We no longer live in an era with single cores!


yeah. but that's been the case for well over 20 years now ;-)

so I don't see that as an argument, in itself.
Feb 24 2022
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 24, 2022 at 11:59:56PM +0000, meta via Digitalmars-d wrote:
[...]

 Nobody said to verbatim copy what C does, I personally explicitly said
 to take that idea and evolve it, just like the newer modern languages
 are properly doing (Go, Zig, Rust, Odin)


Go, Zig, Rust, and Odin all require explicit checking for error returns.
This makes them suffer from exactly the same problem as my C example:
after every single function call you must explicitly check for error
conditions.  It doesn't matter what the implementation mechanism is,
whether it's an int return, or a sum type, or a discriminated union, or
a second return value. The point is that you have to check this error
code *explicitly*, on *every single function call*.

This kind of error handling approach is fundamentally flawed because it
incentivizes programmers to do the absolute minimum they can to shove
the error under the carpet so that they can get on with making progress
in the problem domain. Like ignore the error return value if they can,
write generic "if error ignore it" boilerplate around their code.  Or
just suffer from .unwrap hell.  It clutters code with error-handling
paraphrenalia, making it needlessly verbose, and less composable.

For example, if you have function f that calls g and h, and g and h have
their own set of possible error enums, then what should f return?  You
either create yet another enum that subsumes both (and the caller then
has the hairy task of making sense of which error codes comes from where
and what to do with it), or, if you have to do this for all 65,535
functions in your entire codebase, just give up and go to a global
binary {ok, fail} enum. Or, to harken back to my C example, OK and
INTERNAL_ERR, which is where all return-code-based error handling
inevitably gravitates towards. Which is about as useful as a BSOD every
time the program encounters the slightest difficulty.

A thrown exception allows most code to eliminate all error-handling
paraphrenalia, making code more readable and maintainable, and at the
same time any actual errors are not ignored by default, you have to
handle them somewhere up the call stack. And the exception contains
specific information about the problem, not just the equivalent of
INTERNAL_ERR (or worse, that stinky antipattern of storing an error
message in a global variable that you then have to call some API
function to extract).



 Tagged Unions, Multiple return type, enum/type inference, constructs
 to bubble up things etc.. we must move forward!


I've yet to see a convincing example of error handling based on tagged
unions / multiple returns / etc., that doesn't suffer from the explicit
handling problem I describe above.  If you have one, please enlighten
me.



 I suspect in the near future, exception handling will be seen as very
 bad practice, if not already, we must prepare..


I've always been a skeptic of reacting to hypothetical futures that have
not be proven is inevitable.



 We no longer live in an era with single cores!


Nobody has yet answered my initial question about whether D's exception
throwing mechanism holds a global lock, which is the primary issue
identified in the OP's linked article.  Until this question is answered,
all this talk about exceptions being bad for multi cores is just beating
a strawman.  It's tantamount to saying, since the global lock in C++
exceptions causes performance problems, exceptions must therefore be bad
(even when no global lock exists).  It's a non sequitur.  The problem
observed in the article is caused by the global lock, not by exceptions
per se.  (And whether exceptions in and of themselves necessitate a
global lock has not yet been established.)


T

-- 
May you live all the days of your life. -- Jonathan Swift
Feb 24 2022
next sibling parent reply meta <meta gmail.com> writes:
On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:

 Nobody has yet answered my initial question about whether D's 
 exception throwing mechanism holds a global lock, which is the 
 primary issue identified in the OP's linked article.  Until 
 this question is answered, all this talk about exceptions being 
 bad for multi cores is just beating a strawman.  It's 
 tantamount to saying, since the global lock in C++ exceptions 
 causes performance problems, exceptions must therefore be bad 
 (even when no global lock exists).  It's a non sequitur.  The 
 problem observed in the article is caused by the global lock, 
 not by exceptions per se.  (And whether exceptions in and of 
 themselves necessitate a global lock has not yet been 
 established.)


I don't even think the global lock is the only issue, to begin 
with..

And, no matter what, it's a double penalty in D because it is a 
Heap allocation, and that can pause all the threads if it 
requires more memory.. due to the use of a GC

To counter that, one suggested the use of RC, or a value.. but 
even then, we still deal with exceptions!

No matter what, I personally stopped using exception altogether 
in my C++ projects, and moving forward, in my new D projects too


Also I don't think it is wise to design, or hold designs of, the 
language because you expect people to be lazy, we should have 
design philosophy based on HW and Software constrains, not based 
on lazyness/sloppyness of some developers.. we'll attract the 
wrong user base.. and even then it'll be hard to compete with 
sloppy dynamic languages out there... javascript... to name a few

We should all handle our errors and maintain healthy codebases 
that are safe and make software great again!
Feb 24 2022
next sibling parent reply meta <meta gmail.com> writes:
 I've yet to see a convincing example of error handling based on 
 tagged unions / multiple returns / etc., that doesn't suffer 
 from the explicit handling problem I describe above.  If you 
 have one, please enlighten me.



```D
void parseData() {

     string content = null;

     try {
         content = readFile("poem.txt");
     }
     catch (IOException e) {
         return false;
     }

     if (content.length == 0)
         throw new Exception("No data");

     // parse
}



// either bubble up the exception or handle it
try
{
     parseData();
}
catch ()
{}

```

vs

```zig
fn parseData() !void {

     var content = try readFile("poem.txt") catch {
         // handle error
         IOError => {},
     };

     if (content.len == 0) return err.NoData


    // parse
}


// either bubble up the error or handle it
try parseData();

```

(I'm not sure if that is the right syntax, It's been a while I 
haven't looked at zig)

While the zig version is not perfect, it is nicer, no extra 
indentation for try/catch, you can bubble up the error just like 
with an Exception, you avoid the cost and inconvenience of using 
Exceptions!

It's explicit, and you get to choose if you want to handle them.. 
or not! but at some points you will have to! that's what I call a 
healthy way to manage a code base!

They use enum for errors, and you can extend them if I remember 
correctly

Having multiple return value would make it even better, I'm a fan 
of Go's way, despite what people said about it!


Plus, they are looking to improve it 
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
Feb 24 2022
parent meta <meta gmail.com> writes:
Some interesting points: 
https://www.lighterra.com/papers/exceptionsharmful/
Feb 24 2022
prev sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Friday, 25 February 2022 at 04:09:51 UTC, meta wrote:

 I don't even think the global lock is the only issue, to begin 
 with..

 And, no matter what, it's a double penalty in D because it is a 
 Heap allocation, and that can pause all the threads if it 
 requires more memory.. due to the use of a GC


You can throw pre-allocated exception.


 To counter that, one suggested the use of RC, or a value.. but 
 even then, we still deal with exceptions!

 No matter what, I personally stopped using exception altogether 
 in my C++ projects, and moving forward, in my new D projects too


You've already mentioned this. Would be more interesting to hear 
how you handle errors/exceptions, or propose a better alternative 
to exceptions that would be comfortable for most people.


 Also I don't think it is wise to design, or hold designs of, 
 the language because you expect people to be lazy, we should 
 have design philosophy based on HW and Software constrains, not 
 based on lazyness/sloppyness of some developers.. we'll attract 
 the wrong user base.. and even then it'll be hard to compete 
 with sloppy dynamic languages out there... javascript... to 
 name a few


Laziness is one of driving forces for automation.
Sloppynes is one of causes for good amount of bugs.

Not taking them into account, would only be harmfull.


 We should all handle our errors and maintain healthy codebases 
 that are safe and make software great again!


Per my understanding if-checking of error codes or similar, was 
proven to be inefficient, or at least more inefficient than 
exceptions, for code which errors happen not so often to affect 
performance.
Feb 25 2022
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:

 For example, if you have function f that calls g and h, and g 
 and h have their own set of possible error enums, then what 
 should f return?  You either create yet another enum that 
 subsumes both (and the caller then has the hairy task of making 
 sense of which error codes comes from where and what to do with 
 it), or, if you have to do this for all 65,535 functions in 
 your entire codebase, just give up and go to a global binary 
 {ok, fail} enum. Or, to harken back to my C example, OK and 
 INTERNAL_ERR, which is where all return-code-based error 
 handling inevitably gravitates towards. Which is about as 
 useful as a BSOD every time the program encounters the 
 slightest difficulty.


You can also make your errors dynamically typed. Returning 
exceptions or strings would be ways to achieve this. That way, 
when handling errors, you handle errors you know. If it's some 
unknown exception or error code in a string, you simply return it 
and let the caller handle it. Same as with throwing exceptions, 
except it's manual.

You're right though that being manual is sometimes a downside. On 
the upside, you know when you're using a function that might 
error, because you have to write that error handling wrapper, so 
you don't just accidently propagate that error. But there's a 
temptation to just assert false on an error that could be handled 
or worse, pretend it didn't happen. Especially if you would have 
to change type of the function return to account for errors.

Same thing when reading error-handling code. On the other hand 
it's clutter that obfuscates what the code normally does, but at 
least you're not oblivious to the fact that there's potential for 
abnormal situations.

I suspect that an already written codebase is better off with 
returned error values, assuming they are implemented so that they 
cannot be implicitly discarded. But exceptions are still a good 
choice, because it's less work to implement error handling in the 
first place with them, than with error values.
Feb 25 2022
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:

 Go, Zig, Rust, and Odin all require explicit checking for error 
 returns. This makes them suffer from exactly the same problem 
 as my C example



This is not entirely true, at least for Rust.

Ex.

```
fn foo(i: i32) -> Result<i32, Error> {
     if i % 2 == 0 {
         Ok(i)
     } else {
         Err(/* ... */)
     }
}

fn bar(i: i32) -> Result<i32, Error> {
     let i = match foo(i) {
         Ok(i) => i,
         Err(e) => return Err(e),
     };

     // do something with i
}
```

The function bar can be reduced to:

```
fn bar(i: i32) -> Result<i32, Error> {
     let i = foo(i)?; // The magic happens here

     // do something with i
}
```
Feb 25 2022
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:

 On Thu, Feb 24, 2022 at 11:59:56PM +0000, meta via 
 Digitalmars-d wrote: [...]

 Nobody said to verbatim copy what C does, I personally 
 explicitly said to take that idea and evolve it, just like the 
 newer modern languages are properly doing (Go, Zig, Rust, Odin)


 Go, Zig, Rust, and Odin all require explicit checking for error 
 returns.


Nope: 
http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-question-mark-operator

Years ago, I justified my preference for exceptions because the 
rest of the call stack didn't have to be cluttered with 
"rethrowing". Having to pattern match is better, but still a 
pain. The macro solution they went with is the only one I know of 
that is as easy to use as exceptions without the associated 
baggage.

Atila
Mar 03 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/03/2022 1:05 AM, Atila Neves wrote:

 Go, Zig, Rust, and Odin all require explicit checking for error returns.


 
 Nope: 
 http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-qu
stion-mark-operator 
 
 
 Years ago, I justified my preference for exceptions because the rest of 
 the call stack didn't have to be cluttered with "rethrowing". Having to 
 pattern match is better, but still a pain. The macro solution they went 
 with is the only one I know of that is as easy to use as exceptions 
 without the associated baggage.


We could do something like this, with both isNull methods and a value 
type exception. We just need this extra form of catch statement.

Could be a pretty good simple addition to whatever DIP is put forward.

```diff
Catch:
+	"catch" NoScopeNonEmptyStatement
```
Mar 03 2022
parent reply IGotD- <nise nise.com> writes:
On Thursday, 3 March 2022 at 12:19:44 UTC, rikki cattermole wrote:

 We could do something like this, with both isNull methods and a 
 value type exception. We just need this extra form of catch 
 statement.

 Could be a pretty good simple addition to whatever DIP is put 
 forward.

 ```diff
 Catch:
 +	"catch" NoScopeNonEmptyStatement
 ```


How is it with value type exceptions, would they need typeinfo as 
well? If it needs typeinfo, then it wouldn't work with better C. 
Actually I would rather omitting typeinfo to be a separate 
compiler switch as typeinfo is such a useful feature you should 
be able to pick if you need it or not.

For those embedded systems that have no space for typeinfo, then 
I'd say that value type exception shouldn't work. In those 
systems you probably want full control and your own error 
handling anyway. For embedded system that has a bit more room, 
then value type exceptions together with typeinfo is a good 
compromise.
Mar 03 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 04/03/2022 4:43 AM, IGotD- wrote:

 How is it with value type exceptions, would they need typeinfo as well? 
 If it needs typeinfo, then it wouldn't work with better C. Actually I 
 would rather omitting typeinfo to be a separate compiler switch as 
 typeinfo is such a useful feature you should be able to pick if you need 
 it or not.


They are structs, no TypeInfo required (although the compiler should be 
free to promote class based exceptions to value type as long as the user 
would not notice it).
Mar 03 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 3 March 2022 at 12:05:11 UTC, Atila Neves wrote:

 On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:

 Go, Zig, Rust, and Odin all require explicit checking for 
 error returns.


 Nope: 
 http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-question-mark-operator

 Years ago, I justified my preference for exceptions because the 
 rest of the call stack didn't have to be cluttered with 
 "rethrowing". Having to pattern match is better, but still a 
 pain. The macro solution they went with is the only one I know 
 of that is as easy to use as exceptions without the associated 
 baggage.


Swift has similar syntax sugar with its "try" keyword:

https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html

And of course there are also more general-purpose language 
features like Haskell's "do" notation [1] and Scala's "for" 
comprehensions [2] that handle this as a special case.

[1] https://en.m.wikibooks.org/wiki/Haskell/do_notation
[2] https://docs.scala-lang.org/tour/for-comprehensions.html
Mar 03 2022
parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 3 March 2022 at 15:35:03 UTC, Paul Backus wrote:

 On Thursday, 3 March 2022 at 12:05:11 UTC, Atila Neves wrote:

 On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:

 Go, Zig, Rust, and Odin all require explicit checking for 
 error returns.


 Nope: 
 http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-question-mark-operator

 Years ago, I justified my preference for exceptions because 
 the rest of the call stack didn't have to be cluttered with 
 "rethrowing". Having to pattern match is better, but still a 
 pain. The macro solution they went with is the only one I know 
 of that is as easy to use as exceptions without the associated 
 baggage.


 Swift has similar syntax sugar with its "try" keyword:

 https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html

 And of course there are also more general-purpose language 
 features like Haskell's "do" notation [1] and Scala's "for" 
 comprehensions [2] that handle this as a special case.

 [1] https://en.m.wikibooks.org/wiki/Haskell/do_notation
 [2] https://docs.scala-lang.org/tour/for-comprehensions.html


I didn't know about Swift, thanks for the link.

I left out Haskell on purpose - do notation can do "anything" for 
certain values of "anything". Then people stack monad 
transformers 4 deep and I'm off to the hills. Or would be if I 
wrote Haskell, there's a reason I don't.
Mar 04 2022
prev sibling parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
On Thursday, 24 February 2022 at 20:01:20 UTC, H. S. Teoh wrote:

 The problem with replacing exceptions with return codes is that 
 it requires writing tons of boilerplate to handle error codes. 
 I work with C at work every day, and eventually every function 
 starts looking like this:

 	int some_func(some_type_t *some_args) {
 		int ret = SOME_FUNC_ERR;

 		if ((ret = do_something(...)) != DO_SOMETHING_OK)
 			goto EXIT;

 		if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
 			goto EXIT;

 		if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
 			goto EXIT;

 		// ... ad nauseaum

 		ret = SOME_FUNC_OK;
 	EXIT:
 		return ret;
 	}

 Every single function call must be wrapped with `if ((ret = 
 blah(bleh)) == bluh)` boilerplate,...etc..


Not a comment about your point in general but, yeah, even though 
I agree with your point, in this specific example, you could have 
avoided all the gotos:

int some_func(some_type_t *some_args) {
	int ret = SOME_FUNC_ERR;

	if ((ret = do_something(...)) != DO_SOMETHING_OK)
		return SOME_FUNC_ERR;

	if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
		return SOME_FUNC_ERR;

	if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
		return SOME_FUNC_ERR;


	// ... ad nauseaum

	return SOME_FUNC_OK;
}

But, where I have found it unavoidable (in C) to use this 'goto' 
style (and which - I'm certain - is where your example originates 
from) is when you have some common cleanup to do at the end:

int some_func(some_type_t *some_args) {
	int ret = SOME_FUNC_ERR;

	if ((ret = do_something(...)) != DO_SOMETHING_OK)
		goto EXIT;

	if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
		goto EXIT;

	if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
		goto EXIT;

	// ... ad nauseaum

	ret = SOME_FUNC_OK;
EXIT:
	// ...some cleanup here

	return ret;
}

I have yet to find a way to avoid this in C. OTOH in C++/D/etc 
exceptions are just such a super convenient way to handle this 
case. In code where you are not concerned with the cost of 
exceptions or optimization I'll really miss them.
Feb 25 2022
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 25, 2022 at 10:37:55AM +0000, ShadoLight via Digitalmars-d wrote:
[...]

 Not a comment about your point in general but, yeah, even though I
 agree with your point, in this specific example, you could have
 avoided all the gotos:
 
 int some_func(some_type_t *some_args) {
 	int ret = SOME_FUNC_ERR;
 
 	if ((ret = do_something(...)) != DO_SOMETHING_OK)
 		return SOME_FUNC_ERR;
 
 	if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
 		return SOME_FUNC_ERR;
 
 	if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
 		return SOME_FUNC_ERR;
 
 
 	// ... ad nauseaum
 
 	return SOME_FUNC_OK;
 }
 
 But, where I have found it unavoidable (in C) to use this 'goto' style
 (and which - I'm certain - is where your example originates from) is
 when you have some common cleanup to do at the end:


Yes, I omitted the cleanups, but yeah that's where the goto's come from.
The thing is, sooner or later you're gonna hafta add cleanups. It seems
to be an inevitable fact of life as the function grows more hairs from
bugfixes, enhancements, and what-not.

And experience shows that it's better to just begin by writing the
fully-general form from the beginning than to add it later, because what
tends to happen is that some hapless guy comes along after the fact and
goes "oh right I need to cleanup" and then rewrites some of the return's
to gotos, but misses a few, thus introducing resource leak bugs.


[...]

 I have yet to find a way to avoid this in C. OTOH in C++/D/etc
 exceptions are just such a super convenient way to handle this case.
 In code where you are not concerned with the cost of exceptions or
 optimization I'll really miss them.


That's the thing about people with C/C++ mentality (myself included --
that's the background I come from). You find a case where a particular
construct is less than optimal, and then you decide to forego that
construct entirely, even where performance doesn't really matter and
that construct could have helped your code be cleaner and more
maintainable.

Exceptions seriously help a LOT with making cleaner APIs and in writing
code faster.  Where it becomes a hindrance to runtime performance,
`nothrow` is right there for you to use.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and
let the world mirror it. -- Linus Torvalds
Feb 25 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright 
wrote:

 I agree, which makes this a challenge.

 One solution is to design the return value so that failure is a 
 valid part of the type. For example, searching for X can return 
 an empty result, rather than a special "not found" error.

 Another solution is to redesign the problem. For example, 
 currently Phobos throws on an invalid Unicode character. A 
 better way is to treat such as a "replacement character".


Exceptions are nice because they go under the hood and we can 
catch them ... if we want to. Problem of replacing with return 
values are for example indexing an array and the ArrayIndexError 
exception. 90% of the code we don't check for this as it would be 
a bug in our code but it's a good exception that enables us to 
quickly find the bug. How would it be possible to replace this 
with a return value? One that comes to mind is a tagged union. In 
this case we would want this to be handled silently and behave 
like an exception in readable code. .unwrap hell á la Rust is 
something I want to avoid. However, there are several other ways.

Exceptions from a readable code point of view is desirable, it's 
just that it might be bad for code generation and performance. 
Would should look into fixing this first before we start to 
design something completely new. If we design something 
completely new, then we should make it as similar as traditional 
exceptions.
Feb 24 2022
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 24, 2022 at 08:34:03PM +0000, IGotD- via Digitalmars-d wrote:
[...]

 Exceptions are nice because they go under the hood and we can catch
 them ...  if we want to.


Exactly, it makes APIs cleaner and code more maintainable when you don't
have to litter it with error-handling paraphrenalia all over the place.
Just like how having a GC allows you to eliminate memory-management
paraphrenalia that pollutes, e.g., every C/C++ API. The resulting code
is cleaner, more readable/maintainable, and more easily composable.


[...]

 .unwrap hell á la Rust is something I want to avoid.


Yeah, that's a route I hope we would *not* take in our effort to replace
exceptions.

I've said this before, but I suspect Walter's problem with exceptions
isn't so much the concept of exceptions itself, but rather with the
current implementation, which we inherited from C++. There's got to be a
way of working with exception-like syntax and convenience without the
performance hit *and* without the proliferation of error-code handling
boilerplate.


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.
Feb 24 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2022 12:34 PM, IGotD- wrote:

 Exceptions are nice because they go under the hood and we can catch them ...
if 
 we want to. Problem of replacing with return values are for example indexing
an 
 array and the ArrayIndexError exception.


Array overflows are a "terminate the program" thing, as they are program bugs. 
Program bugs are not in the purview of exceptions.
Feb 24 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright 
wrote:

 I agree, which makes this a challenge.

 One solution is to design the return value so that failure is a 
 valid part of the type. For example, searching for X can return 
 an empty result, rather than a special "not found" error.

 Another solution is to redesign the problem. For example, 
 currently Phobos throws on an invalid Unicode character. A 
 better way is to treat such as a "replacement character".


Since you want to go that route and it might be applicable and 
convenient for some interfaces, you should consider adding a 
nullable type i D, and a language native nullable not only a 
library template type. You cannot find a "magic value" for all 
interfaces and a nullable type would solve that.


nullable type (because I like it). The '?' makes it easy to 
implement and encourage people to use it.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types



they need compiled code or for whatever reason. When they see 

"modern C++".
Mar 01 2022
next sibling parent bauss <jj_1337 live.dk> writes:
On Wednesday, 2 March 2022 at 00:03:48 UTC, IGotD- wrote:

 On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright 
 wrote:

 I agree, which makes this a challenge.

 One solution is to design the return value so that failure is 
 a valid part of the type. For example, searching for X can 
 return an empty result, rather than a special "not found" 
 error.

 Another solution is to redesign the problem. For example, 
 currently Phobos throws on an invalid Unicode character. A 
 better way is to treat such as a "replacement character".


 Since you want to go that route and it might be applicable and 
 convenient for some interfaces, you should consider adding a 
 nullable type i D, and a language native nullable not only a 
 library template type. You cannot find a "magic value" for all 
 interfaces and a nullable type would solve that.


 nullable type (because I like it). The '?' makes it easy to 
 implement and encourage people to use it.

 https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types



 they need compiled code or for whatever reason. When they see 

 "modern C++".



was still missing a lot of the modern features like built-in 
tuples, method shortened syntax, async/await was barely a thing 
(I believe it was started to be introduced.) and so on. However I 

miss when I go back to D, it used to be the other way around.
Mar 01 2022
prev sibling parent meta <meta gmail.com> writes:
On Wednesday, 2 March 2022 at 00:03:48 UTC, IGotD- wrote:

 On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright 
 wrote:

 I agree, which makes this a challenge.

 One solution is to design the return value so that failure is 
 a valid part of the type. For example, searching for X can 
 return an empty result, rather than a special "not found" 
 error.

 Another solution is to redesign the problem. For example, 
 currently Phobos throws on an invalid Unicode character. A 
 better way is to treat such as a "replacement character".


 Since you want to go that route and it might be applicable and 
 convenient for some interfaces, you should consider adding a 
 nullable type i D, and a language native nullable not only a 
 library template type. You cannot find a "magic value" for all 
 interfaces and a nullable type would solve that.


 nullable type (because I like it). The '?' makes it easy to 
 implement and encourage people to use it.

 https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types



 they need compiled code or for whatever reason. When they see 

 "modern C++".


That's indeed a nice way to represent nullable/optional, I 
personally prefer calling such feature as "optional", null is 
already a thing when playing with pointers, that'd cause 
confusion to call it nullable imo
Mar 02 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Thursday, 24 February 2022 at 05:05:27 UTC, Walter Bright 
wrote:

 On 2/23/2022 4:19 PM, meta wrote:

 I moved away from them completly in C++, i wish i could do the 
 same with D..


 dmd does not use exceptions at all.

 One of the requirements I proposed for Phobos2 was for it to 
 not use exceptions.


Well, now it's me that is 'confused'.

That is, how do I reconcile your above statement with your 
previous statement:

"Why exceptions for error handling is so important" - Walter 
Bright.

https://forum.dlang.org/post/m8tkfm$ret$1 digitalmars.com
Feb 24 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 24 February 2022 at 08:05:42 UTC, forkit wrote:


 That is, how do I reconcile your above statement with your 
 previous statement:

 "Why exceptions for error handling is so important" - Walter 
 Bright.


The fact that D has had exceptions from the beginning shows he 
thought they were a good idea before. Opinions evolve over time.
Feb 24 2022
parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 24 February 2022 at 12:33:04 UTC, Mike Parker wrote:

 On Thursday, 24 February 2022 at 08:05:42 UTC, forkit wrote:


 That is, how do I reconcile your above statement with your 
 previous statement:

 "Why exceptions for error handling is so important" - Walter 
 Bright.


 The fact that D has had exceptions from the beginning shows he 
 thought they were a good idea before. Opinions evolve over time.


I don't see what from the discussion here and from the original 
document demonstrate exception to be a bad idea.

In fact, in the benchmark they propose, all alternative solution 
are slower in the fast path. The tradeof that is proposed by 
exceptions is the following: have as little impact as possible on 
the fast path, at the cost of making the exceptional path 
significantly slower.

This is a worthy tradeof.

And when I'm saying getting out of the way, I'm not talking 
exclusively run time, but also for the developer: there is no 
need to litter the code with numerous exception handling path all 
over the place.

I'm not sure I understand why C++ exception need to take a lock. 
What have they done this time to deserve this?
Feb 24 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 24 February 2022 at 13:19:55 UTC, deadalnix wrote:


 I don't see what from the discussion here and from the original 
 document demonstrate exception to be a bad idea.


I was just responding to forkit's "confusion" about the 
contradiction between Walter's current stance and his past one. 
I'll leave it to Walter to explain his current thinking, as I 
can't recall what he's said about it.
Feb 24 2022
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 24 February 2022 at 13:28:23 UTC, Mike Parker wrote:

 On Thursday, 24 February 2022 at 13:19:55 UTC, deadalnix wrote:


 I don't see what from the discussion here and from the 
 original document demonstrate exception to be a bad idea.


 I was just responding to forkit's "confusion" about the 
 contradiction between Walter's current stance and his past one. 
 I'll leave it to Walter to explain his current thinking, as I 
 can't recall what he's said about it.


Okay, here we go:

https://www.youtube.com/watch?v=g26eJcs2QB0&t=0s
Feb 24 2022
parent reply forkit <forkit gmail.com> writes:
On Thursday, 24 February 2022 at 13:36:29 UTC, Mike Parker wrote:

 On Thursday, 24 February 2022 at 13:28:23 UTC, Mike Parker 
 wrote:

 On Thursday, 24 February 2022 at 13:19:55 UTC, deadalnix wrote:


 I don't see what from the discussion here and from the 
 original document demonstrate exception to be a bad idea.


 I was just responding to forkit's "confusion" about the 
 contradiction between Walter's current stance and his past 
 one. I'll leave it to Walter to explain his current thinking, 
 as I can't recall what he's said about it.


 Okay, here we go:

 https://www.youtube.com/watch?v=g26eJcs2QB0&t=0s


thanks. for those interested, it's 31 minutes into the talk:

https://youtu.be/g26eJcs2QB0?t=1809

 From what I can grasp, Walter seems not too convinced about 
possible solutions to removing exceptions. His main gripe with 
exceptions seems to be -> "there are a lot of paths in your code 
that you've never thought about".

In any case, when looking at Herbs paper, I'm reminded of what 
Jon Skeet said about exceptions:

" ... in almost every situation where the performance of 
exceptions would be significant, there are bigger design problems 
to worry about."

and..

"When designing the contract of a method, it's worth considering 
whether it's reasonable to call that method in a fairly tight 
loop, continuing to call it even if the previous call fails. In 
that case, it may be worth having two methods, one of which uses 
exceptions to indicate errors and one of which doesn't (like 
Parse and TryParse) but in all other situations, using exceptions 
is unlikely to cause performance problems, but is likely to make 
the calling code much easier to understand.

https://jonskeet.uk/csharp/exceptions.html

Now I don't know too much about exception handling in C++, but 
personally, the above advice has always served me (and my 
end-users) well.

Replacing exceptions with some radical change, will need to be 
well justified, and nobody (as far as I can tell), has done that.
Feb 24 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 24 February 2022 at 20:27:50 UTC, forkit wrote:

 Replacing exceptions with some radical change, will need to be 
 well justified, and nobody (as far as I can tell), has done 
 that.


Yes, the whole discussion is bogus. The only reason to not use 
exceptions in C++ is in embedded or in inner loops (where you 
typically don't need them anyway). The motivation for providing 
an alternative to exceptions in C++ is that not having an 
embedded-friendly standard library is problematic. It is harmful 
to their eco system.

D needs to focus on core issues. This is not a core issue for D. 
D needs to focus on usability and memory management issues first, 
which is hurting D's eco system.

Or, just *focus* in general… Being all over the map all the time 
is not a good thing for a design process.
Feb 25 2022
parent reply forkit <forkit gmail.com> writes:
On Friday, 25 February 2022 at 08:40:12 UTC, Ola Fosheim Grøstad 
wrote:

 ... The motivation for providing an alternative to exceptions 
 in C++ is that not having an embedded-friendly standard library 
 is problematic. It is harmful to their eco system.
 ..


The 'real' motivation is simple -> an increased awareness of the 
benefits of Rust within the C++ community.

That is, C++ now has a genuine competitor -> and C++ now needs to 
compete, or risk losing market share.

So I expect we'll see a noticable increase in ideas and 
innovation coming out of the C++ community, particuly in areas 
where Rust does it better.

D should also remain alert to what's going on ;-)
Feb 25 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:

 On Friday, 25 February 2022 at 08:40:12 UTC, Ola Fosheim 
 Grøstad wrote:

 ... The motivation for providing an alternative to exceptions 
 in C++ is that not having an embedded-friendly standard 
 library is problematic. It is harmful to their eco system.
 ..


 The 'real' motivation is simple -> an increased awareness of 
 the benefits of Rust within the C++ community.

 That is, C++ now has a genuine competitor -> and C++ now needs 
 to compete, or risk losing market share.

 So I expect we'll see a noticable increase in ideas and 
 innovation coming out of the C++ community, particuly in areas 
 where Rust does it better.

 D should also remain alert to what's going on ;-)


In terms of ecosystem, Rust is where C++ was 30 years ago.

While its ideas might seem to be a risk to C++, specially since 
there is no way to fix unsafe by default in C++ without breaking 
backwards compatibility.

However until we get Metal rewritten in Rust, CUDA Rust, 
Tensorflow/Pytorch rewritten in Rust, LLVM/GCV rewritten in Rust, 
AUTOSAR and SYSCL move from C++ to Rust, Nintendo/Sony/Microsoft 
console SDK support for Rust, CERN, Fermilab, NASA moving away 
from Fortran/C++.....

There is no market share for Rust to take away from C++ on those 
domains.

Currently D has more to lose against Rust than C++, because it 
lacks such deep ingrained industry support, and trying to be just 
like Rust won't be differentiating factor.
Feb 26 2022
next sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto wrote:

 In terms of ecosystem, Rust is where C++ was 30 years ago.


I think that's a little overstated - were you even around in 1992 
??

Microsoft released their first C++ compiler in 1992.

Anyway. It's curious that Microsoft has taken a very noticable 
interest in Rust:

https://docs.microsoft.com/en-us/windows/dev-environment/
Feb 26 2022
next sibling parent forkit <forkit gmail.com> writes:
On Saturday, 26 February 2022 at 10:20:00 UTC, forkit wrote:

 On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto 
 wrote:

 In terms of ecosystem, Rust is where C++ was 30 years ago.




Here's a pretty good analysis of the Rust ecosystem.

https://joeprevite.com/rust-lang-ecosystem/
Feb 26 2022
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 26 February 2022 at 10:20:00 UTC, forkit wrote:

 On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto 
 wrote:

 In terms of ecosystem, Rust is where C++ was 30 years ago.


 I think that's a little overstated - were you even around in 
 1992 ??

 Microsoft released their first C++ compiler in 1992.

 Anyway. It's curious that Microsoft has taken a very noticable 
 interest in Rust:

 https://docs.microsoft.com/en-us/windows/dev-environment/


Given that my first coding platform was the Timex 2068 I guess I 
was.

Microsoft was the last C compiler vendor to adopt C++ with the 
release of Microsoft C/C++ 7.0.

I leave as exercise for the reader when everyone else released 
their offerings, including frameworks like Turbo Vision, 
AppFramework and Motif++.

Microsoft is only testing waters with Rust, until it comes up in 
Visual Studio, with comparable tooling to .NET and C++, for all 
kinds of Azure and Windows workloads, 99% of Microsoft shops 
won't bother.
Feb 26 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto wrote:

 On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:



 Currently D has more to lose against Rust than C++, because it 
 lacks such deep ingrained industry support, and trying to be 
 just like Rust won't be differentiating factor.



`D` can be dedicated to programmers.
Let `Rust` serve big factories.
The key is to position.
Don't be greedy, drop `D` own `cons`,and attract entrepreneurs of 
`small and micro` enterprises, which is victory!
D need more `innovation`.
Let others go with me.
No need to copy others.
Feb 26 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:

 The 'real' motivation is simple -> an increased awareness of 
 the benefits of Rust within the C++ community.

 That is, C++ now has a genuine competitor -> and C++ now needs 
 to compete, or risk losing market share.


Maybe, but how many committed C++ programmers have switched to 
Rust?


 So I expect we'll see a noticable increase in ideas and 
 innovation coming out of the C++ community, particuly in areas 
 where Rust does it better.


Yes, but it will probably come in the form of being "optional". 
Many of the improvements in C++ comes from compiler/tooling 
support/switches or things that can pass as library extensions 
(but really only makes sense with compiler support). I don't 
think we will see much in the shape of changes to the core 
language.


 D should also remain alert to what's going on ;-)


D should form its own vision, and focus on that vision. Only then 
will real improvements be possible. Too many DIPs touch on things 
that have no significant impact. If it has no significant impact 
then it should not be a priority. Without a vision it difficult 
to assess what the priorities ought to be.

For C++ you can say that the vision is to support existing fields 
where it is widely used better. They have many use cases to 
analyse. So that is a very different situation.

I think what the priorities ought to be is more clear for C++ as 
it have many specific niche areas where it is heavily used.
Feb 26 2022
parent reply forkit <forkit gmail.com> writes:
On Saturday, 26 February 2022 at 13:48:52 UTC, Ola Fosheim 
Grøstad wrote:

 Maybe, but how many committed C++ programmers have switched to 
 Rust?


so you don't compete in the market, by waiting till your 
competitor has taken your customers ;-)



 Yes, but it will probably come in the form of being "optional". 
 Many of the improvements in C++ comes from compiler/tooling 
 support/switches or things that can pass as library extensions 
 (but really only makes sense with compiler support). I don't 
 think we will see much in the shape of changes to the core 
 language.


 D should form its own vision, and focus on that vision. Only 
 then will real improvements be possible. Too many DIPs touch on 
 things that have no significant impact. If it has no 
 significant impact then it should not be a priority. Without a 
 vision it difficult to assess what the priorities ought to be.


D seems to becoming more of a development environment for C code.

Seriously. If I want C, I can just use C.

So just where D is going to stand out (in relation to it's 
competitors) in this new world of 'more secure code', is not at 
all clear to me, and it's vision is even more obscure to me.



 For C++ you can say that the vision is to support existing 
 fields where it is widely used better. They have many use cases 
 to analyse. So that is a very different situation.

 I think what the priorities ought to be is more clear for C++ 
 as it have many specific niche areas where it is heavily used.


This would be sign of impending doom for C++. i.e. It *also* 
needs to focus heavily on competing for new customers, now that 
many people and corporations see Rust as serious contender.

I remind you, that the info in this link is somewhat outdated ;-)

(i.e. the Rust ecosystem has grown further since this analysis).

https://joeprevite.com/rust-lang-ecosystem/
Feb 26 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 26 February 2022 at 20:47:27 UTC, forkit wrote:

 On Saturday, 26 February 2022 at 13:48:52 UTC, Ola Fosheim 
 Grøstad wrote:

 Maybe, but how many committed C++ programmers have switched to 
 Rust?


 so you don't compete in the market, by waiting till your 
 competitor has taken your customers ;-)


Or you don't fall into the trap of trying to be everything for 
everybody and ending up with a design that doesn't satisfy anyone.


 D seems to becoming more of a development environment for C 
 code.

 Seriously. If I want C, I can just use C.


Yes, that does not work. The only thing C has going for it is 
critical mass. Nobody can compete with C, as the selling point of 
C is its history.  So, that would be a loose-loose strategy.


 So just where D is going to stand out (in relation to it's 
 competitors) in this new world of 'more secure code', is not at 
 all clear to me, and it's vision is even more obscure to me.


The vision has not been elaborated in way that is meaningful, I 
agree.

In my view the vision ought to be to switch to local GC for 
non-shared and ARC for shared objects, and gear the eco system 
towards an actor model that make good use of a wide range of CPU 
configurations (e.g. run equally well on 2 cores, 32 cores, and 
so on). But that is not the current vision, that is just what I 
personally think would make sense for the current user base.


 This would be sign of impending doom for C++. i.e. It *also* 
 needs to focus heavily on competing for new customers, now that 
 many people and corporations see Rust as serious contender.


I don't think so. C++ can afford to loose some customers in some 
application domains and strengthen its positions in areas where 
it is most suitable. Changing the core language would be a 
mistake for C++ because it has critical mass, way more so than 
any other competitor.

That "critical mass" is the key issue, so what is good for C++ 
does not translate to other languages.
Feb 26 2022
parent reply forkit <forkit gmail.com> writes:
On Saturday, 26 February 2022 at 23:00:24 UTC, Ola Fosheim 
Grøstad wrote:

 That "critical mass" is the key issue, so what is good for C++ 
 does not translate to other languages.


c++'s critical mass is more of happy accident, than anything 
(i.e. there were no serious contenders for that same market at 
the time, or for a very long time since).

Same is true for C.

Same is true for Java.



There are plenty eager to see a better c++.

I personally do not think Rust is that alternative. Why? Because 
they used computer science alone to create a new language for 
'modern times'.

Instead, they should have combined computer science with 
psychological science, and they would have come up with a better 
syntax that is less cognitively challenging (something C++ is 
working hard towards.. well..in part).
Feb 26 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 27 February 2022 at 01:29:58 UTC, forkit wrote:

 Instead, they should have combined computer science with 
 psychological science, and they would have come up with a 
 better syntax that is less cognitively challenging (something 
 C++ is working hard towards.. well..in part).


Yes, they have looked at bloat and come up with simple solutions 
that work well, such as replacing "function objects" with lambdas.

However, usability in 2022 means IDE-friendly. C++ and D are not 
particularly friendly to people creating advanced IDEs.

C++ will probably be replaced with a language that allows new and 
better ways to express programming ideas in the form of IDEs 
(with graphical modelling support etc). Let's hope it is 
something far better than the current challengers.
Feb 27 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 27 February 2022 at 08:07:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 27 February 2022 at 01:29:58 UTC, forkit wrote:

 Instead, they should have combined computer science with 
 psychological science, and they would have come up with a 
 better syntax that is less cognitively challenging (something 
 C++ is working hard towards.. well..in part).


 Yes, they have looked at bloat and come up with simple 
 solutions that work well, such as replacing "function objects" 
 with lambdas.

 However, usability in 2022 means IDE-friendly. C++ and D are 
 not particularly friendly to people creating advanced IDEs.

 C++ will probably be replaced with a language that allows new 
 and better ways to express programming ideas in the form of 
 IDEs (with graphical modelling support etc). Let's hope it is 
 something far better than the current challengers.


Qt, Clion and Visual Studio are doing just fine for C++, by 
adopting the ideas that were already being explored a couple of 
decades ago, via language servers.

In fact, during the early 90's two companies companies already 
went down this path, Lucid and IBM.

Lucid with Energize (1993 Demo: 
https://www.youtube.com/watch?v=pQQTScuApWk), using a DB for the 
C++ AST (https://dreamsongs.com/Cadillac.html).

IBM with the release of Visual Age for C++ v4.0, which used a 
Smalltalk like image for C++ code,  
http://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review

Both failed in the market, because they required quite expensive 
workstations to be usable, however their requirements are a joke 
now when compared with what most people phones are running.

So naturally, all major C++ IDEs are now adding back those 
features.

Visual Studio 2022 allows me to use C++ almost like .NET, easily 
hot reloading modified code, and it isn't the only C++ 
environment offering such kind of goodies.

https://www.youtube.com/watch?v=x_gr6DNrJuM

https://liveplusplus.tech/

By the way, NVidia now has a A Team collection of C++ people, it 
is quite clear that C++ has won the wars of programming GPU 
hardware and SYSCL will cement the same for FPGA design.
Feb 27 2022
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 27 February 2022 at 10:16:23 UTC, Paulo Pinto wrote:
...

 By the way, NVidia now has a A Team collection of C++ people,


Yes, good work is being done there, some of which can be co-opted 
today by dcompute pioneers.  The CUB library, in particular, is 
worth a look.  It shows how world class GPU performance can be 
achieved using C++.  It also, much like Boost, reminds one of how 
fortunate we are to have D.


 it is quite clear that C++ has won the wars of programming GPU 
 hardware and SYSCL will cement the same for FPGA design.


Without a doubt C++ is quite popular in the GPU space, I used 
C++/CUDA myself for years but, even in its 
early/can-certainly-improve form, I much prefer dcompute.

C++ is today's safe choice for both CPU and GPU performance work 
but less conservative programmers/companies would do well to 
examine alternatives.  The productivity improvement can be (was 
for me) substantial.

Finally, if D/dcompute is just too risky for you I'd suggest 
taking a look at Sean Baxter's circle variant of C++.  If 
D/dcompute were unavailable I'd take circle for a spin.
Feb 27 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 27 February 2022 at 15:17:01 UTC, Bruce Carneal wrote:

 C++ is today's safe choice


One problem is that the people left in C++ have avoided going 

population that said no those AND to the newer native languages 
skews towards very conservative choices. As such no language seen 
as "alternative" enter their worldview because "only C++ can do 
it".

Even if you compete with them, the C++ competition will still 
won't believe there are alternatives to C++. In the real world, 
starting a C++ codebase today is much less cost-effective than in 
D, and this debt cause a lot of dividend payments, and also it 
costs a lot of senior C++ engineers to make sense of the most 
complicated programming language we have.

The only way is to displace the incumbent not convince them.
Feb 27 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 27 February 2022 at 16:37:42 UTC, Guillaume Piolat 
wrote:

 On Sunday, 27 February 2022 at 15:17:01 UTC, Bruce Carneal 
 wrote:

 C++ is today's safe choice


 One problem is that the people left in C++ have avoided going 

 population that said no those AND to the newer native languages 
 skews towards very conservative choices. As such no language 
 seen as "alternative" enter their worldview because "only C++ 
 can do it".

 Even if you compete with them, the C++ competition will still 
 won't believe there are alternatives to C++. In the real world, 
 starting a C++ codebase today is much less cost-effective than 
 in D, and this debt cause a lot of dividend payments, and also 
 it costs a lot of senior C++ engineers to make sense of the 
 most complicated programming language we have.

 The only way is to displace the incumbent not convince them.


Languages one their own are meaningless, you aren't competing 
with C++, you are competing with platforms and industry standards 
that happen to make use of C++.

Disrupting those platforms and industry standards with D, that 
should be the focus.
Feb 27 2022
parent meta <meta gmail.com> writes:
On Sunday, 27 February 2022 at 16:56:41 UTC, Paulo Pinto wrote:

 Languages one their own are meaningless, you aren't competing 
 with C++, you are competing with platforms and industry 
 standards that happen to make use of C++.

 Disrupting those platforms and industry standards with D, that 
 should be the focus.


I agree with this so much, you nailed it!
Feb 27 2022
prev sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 27 February 2022 at 16:37:42 UTC, Guillaume Piolat 
wrote:

 On Sunday, 27 February 2022 at 15:17:01 UTC, Bruce Carneal 
 wrote:

 C++ is today's safe choice


 One problem is that the people left in C++ have avoided going 

 population that said no those AND to the newer native languages 
 skews towards very conservative choices. As such no language 
 seen as "alternative" enter their worldview because "only C++ 
 can do it".


Yes.  It's frustrating and pointless to try to "convince" those 
who have made up their mind, doubly so with those who lazily 
prefer to predict failure for anything new rather than cheer on 
others working to improve upon the status quo.


 Even if you compete with them, the C++ competition will still 
 won't believe there are alternatives to C++. In the real world, 
 starting a C++ codebase today is much less cost-effective than 
 in D, and this debt cause a lot of dividend payments, and also 
 it costs a lot of senior C++ engineers to make sense of the 
 most complicated programming language we have.


Yes.  Staying with C++, especially if you've got a very large 
code base, makes more sense to me than *starting* a new C++ 
project.
Feb 27 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal wrote:

 ...

 Yes.  Staying with C++, especially if you've got a very large 
 code base, makes more sense to me than *starting* a new C++ 
 project.


How do you start a new project in D for PlayStation 5/Switch/XBox 
or get a AUTOSAR certification for deployment of D written 
software?

Unless one is willing to do the work Unity has been doing with 

choice, rather those.
Feb 27 2022
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

 How do you start a new project in D for PlayStation 
 5/Switch/XBox


You get LDC/GCC to emit binary code for whatever platform they 
are using, and port the needed system headers (with agreement 
from the vendor) to your desired language. Chances are, the 
headers are in C or C-ABI C++ for that reason.



 or get a AUTOSAR certification for deployment of D written 
 software?


People are writing software for ships with D, so probably they 
can use D for cars.



 Unless one is willing to do the work Unity has been doing with 

 choice, rather those.


You can write bindings for just the API you need. Plus if you go 
the BindBC way, it break all linking dependencies, making it 
really easy to port and possibly be more portable than the native 
vendor SDK. Bonus points: build fast and you avoid, say, an IDE 
lock-in.

For Auburn Sounds we translated headers and implemented 
VST2/VST3/AU/AAX/LV2 and Apple headers. We re-used X11 headers 
translated by somebody in the D community. All this work is 
manual and not particularly heroic, as you pay it only _once_. 


Writing GPGPU in D is not any more complicated than adding the 
DUB line for derelict-cuda or derelict-opencl really.

It's really simple, writing bindings and platform support is 
usually a one-time cost to pay, while using an unproductive 
language is a lifetime and mental cost that will close product 
opportunities by being annoying day-in, day-out.

If you want to use D (and you should) you are going to make the 
platform support as you go.

A freelancer wouldn't recoup the cost, but a product-based 
business will.
Feb 27 2022
prev sibling next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

 On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal 
 wrote:

 ...

 Yes.  Staying with C++, especially if you've got a very large 
 code base, makes more sense to me than *starting* a new C++ 
 project.


 How do you start a new project in D for PlayStation 
 5/Switch/XBox or get a AUTOSAR certification for deployment of 
 D written software?


We're a ways out but SPIR-V looks like it has opened a path to 
multi-language deployments on the consoles.  I've not looked at 
the AUTOSAR world.


 Unless one is willing to do the work Unity has been doing with 

 choice, rather those.


I agree.  If the effort involved in getting D off the ground in a 
new domain outweighs the perceived long range benefits then I'd 
expect the team tackling a new project to have chosen another 
language.  I view such choices as an indication of where D was 
when those choices were made rather than as a pronouncement of 
permanent exclusion.

I believe that D can and will evolve to lower the costs of 
entering new domains: seamless/automated importC "bindings", 
better support in SoC environments, dcompute maturation, ... 
As/if it does, the economics change and we're likely to see 
forays into new areas.
Feb 27 2022
prev sibling parent reply meta <meta gmail.com> writes:
On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

 On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal 
 wrote:

 ...

 Yes.  Staying with C++, especially if you've got a very large 
 code base, makes more sense to me than *starting* a new C++ 
 project.


 How do you start a new project in D for PlayStation 
 5/Switch/XBox or get a AUTOSAR certification for deployment of 
 D written software?

 Unless one is willing to do the work Unity has been doing with 

 choice, rather those.



using IL2CPP, then they compile the C++ to target the various 
platforms..


You guys enumerates features that competes with C/C++/Rust, why 

to hit walls rather than profiting from D's strengths as a System 
language..

There is 2 visions for the languages that is clashing, sorting 
this out should be the priority.. it obviously prevents us to 
move forward..
Feb 27 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 28 February 2022 at 01:47:47 UTC, meta wrote:

 On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

 On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal 
 wrote:

 ...

 Yes.  Staying with C++, especially if you've got a very large 
 code base, makes more sense to me than *starting* a new C++ 
 project.


 How do you start a new project in D for PlayStation 
 5/Switch/XBox or get a AUTOSAR certification for deployment of 
 D written software?

 Unless one is willing to do the work Unity has been doing with 

 the choice, rather those.



 code, using IL2CPP, then they compile the C++ to target the 
 various platforms..


 You guys enumerates features that competes with C/C++/Rust, why 

 wants to hit walls rather than profiting from D's strengths as 
 a System language..

 There is 2 visions for the languages that is clashing, sorting 
 this out should be the priority.. it obviously prevents us to 
 move forward..


Unity is shipping machine code into consoles.



C++ used to be a source translator into C until Walter shipped 
the first proper compiler, so what.

Whatever vision, doesn't matter if D doesn't know where it wants 
to be.


here is where the idea comes from.
Feb 27 2022
next sibling parent meta <meta gmail.com> writes:
On Monday, 28 February 2022 at 06:40:32 UTC, Paulo Pinto wrote:

 On Monday, 28 February 2022 at 01:47:47 UTC, meta wrote:

 On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

 On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal 
 wrote:

 ...

 Yes.  Staying with C++, especially if you've got a very 
 large code base, makes more sense to me than *starting* a 
 new C++ project.


 How do you start a new project in D for PlayStation 
 5/Switch/XBox or get a AUTOSAR certification for deployment 
 of D written software?

 Unless one is willing to do the work Unity has been doing 

 to the choice, rather those.



 code, using IL2CPP, then they compile the C++ to target the 
 various platforms..


 You guys enumerates features that competes with C/C++/Rust, 

 wants to hit walls rather than profiting from D's strengths as 
 a System language..

 There is 2 visions for the languages that is clashing, sorting 
 this out should be the priority.. it obviously prevents us to 
 move forward..


 Unity is shipping machine code into consoles.



 C++ used to be a source translator into C until Walter shipped 
 the first proper compiler, so what.

 Whatever vision, doesn't matter if D doesn't know where it 
 wants to be.


 so here is where the idea comes from.


It is relevant


Code


Scripting could be replaced by anything, it doesn't matter, it's 
flavor of the month (decade here but the point is still valid)

You said it right, we should do what C++ do best, and the reason 
why C/C++ are still used today

D is well positioned to be:

     Engine:D -> Scripting:D -> Output:Machine Code

Removing the unnecessary extra step..

Reducing the complexity of Unity as a whole, that's our strength, 
scripting part shouldn't make us forgot what's the initial 
foundation, a solid system language!

But at this point we are being a little bit out of topic..
Feb 28 2022
prev sibling parent meta <meta gmail.com> writes:
On Monday, 28 February 2022 at 06:40:32 UTC, Paulo Pinto wrote:

 Whatever vision, doesn't matter if D doesn't know where it 
 wants to be.


 so here is where the idea comes from.


I agree, it is a huge missed opportunity..
Feb 28 2022
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 27 February 2022 at 10:16:23 UTC, Paulo Pinto wrote:

 By the way, NVidia now has a A Team collection of C++ people, 
 it is quite clear that C++ has won the wars of programming GPU 
 hardware and SYSCL will cement the same for FPGA design.


I think that that is not at all the case. If anything its more 
that CUDA has won in the GPU space, to the detriment of OpenCL, 
because of its relative ease of use.
Mar 03 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 4 March 2022 at 03:42:04 UTC, Nicholas Wilson wrote:

 On Sunday, 27 February 2022 at 10:16:23 UTC, Paulo Pinto wrote:

 By the way, NVidia now has a A Team collection of C++ people, 
 it is quite clear that C++ has won the wars of programming GPU 
 hardware and SYSCL will cement the same for FPGA design.


 I think that that is not at all the case. If anything its more 
 that CUDA has won in the GPU space, to the detriment of OpenCL, 
 because of its relative ease of use.


Be as it may be, C++ found its niche, like SQL on RDMS, and 
NVidia employs quite a few ISO C++ contributors.
Mar 03 2022
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 27 February 2022 at 01:29:58 UTC, forkit wrote:

 On Saturday, 26 February 2022 at 23:00:24 UTC, Ola Fosheim 
 Grøstad wrote:

 That "critical mass" is the key issue, so what is good for C++ 
 does not translate to other languages.


 c++'s critical mass is more of happy accident, than anything 
 (i.e. there were no serious contenders for that same market at 
 the time, or for a very long time since).

 Same is true for C.

 Same is true for Java.



 There are plenty eager to see a better c++.

 I personally do not think Rust is that alternative. Why? 
 Because they used computer science alone to create a new 
 language for 'modern times'.

 Instead, they should have combined computer science with 
 psychological science, and they would have come up with a 
 better syntax that is less cognitively challenging (something 
 C++ is working hard towards.. well..in part).


Why do I still bother with C++, when my work languages are Java 
and .NET languages?

While they stole C++'s thunder on GUI and distributed computing, 
their runtimes, or native bindings to the host platforms, or 
GPGPU programming bindings, require dealing with C++ in one way 
or the other.

Using D instead, would be great, but in those scenarios it would 
be adding just another layer to debug between the work that has 
to be delivered in Java/.NET anyway, and the SDKs that are C++ 
only, so why bother.

Same applies to any language pretending to take away C++'s throne 
in such domains.

What D needs is focus on being great at a specific domain, as 
most IT departments pick languages based on platforms, not the 
other way around.
Feb 27 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:

 The 'real' motivation is simple -> an increased awareness of 
 the benefits of Rust within the C++ community.


It seems to be some kind false narrative that Rust is savior of 
all and will create a new world. The more I learn Rust, the more 
I realize that's not the case.

If you look at Rust error handling (the proposed std::Result) it 

others). D can even handle multiple exceptions, even if that is 
seldom used. Basically you can catch any exception up the call 
chain and polymorphism really makes this possible. It is easy to 
add new exceptions as well as reusing existing ones thanks to 
this.

If you look at Rust Result<T, E>, it is basically a wrapped 
return value and the type in E must be known to the caller so 
cannot easily pass it up the chain. Type E can be anything but 
adding your own error types becomes cumbersome. Rust might also 
provide an Error trait (Rust way of structs with virtual methods) 
which is more generic so that you can add your own custom error 
type. However, this Error trait is in general allocated on the 
heap so not even Rust is immune to heap allocated error handling.

For simpler error handling Result<T, E> is a better match as E is 
in general an immutable string, an integer or nothing.
Feb 26 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 26 February 2022 at 20:59:53 UTC, IGotD- wrote:

 On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:

 [...]


 It seems to be some kind false narrative that Rust is savior of 
 all and will create a new world. The more I learn Rust, the 
 more I realize that's not the case.

 [...]


Case in point,

https://nnethercote.github.io/2022/02/25/how-to-speed-up-the-rust-compiler-in-2022.html


  Decoder trait used for metadata decoding was fallible, using 
 Result throughout. But decoding failures should only happen if 
 something highly unexpected happens (e.g. metadata is 
 corrupted) and on failure the calling code would just abort. 
 This PR changed Decoder to be infallible throughout—panicking 
 immediately instead of panicking slightly later—thus avoiding 
 lots of pointless Result propagation, for wins across many 
 benchmarks of up to 2%.


Beware of always copying other language designs.
Feb 26 2022
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 26, 2022 at 08:59:53PM +0000, IGotD- via Digitalmars-d wrote:
[...]

 It seems to be some kind false narrative that Rust is savior of all
 and will create a new world. The more I learn Rust, the more I realize
 that's not the case.


Exactly.  The Rust hype these days are reminiscient of the Java hype
back in the 90's.  Java was touted as the be-all and end-all of
programming that will solve all of your programming problems and present
none of its own. Well, 30 years later we have learned some good things
from Java, but we have also realized its shortcomings, and that it's
really NOT what it was originally hyped to be.



 If you look at Rust error handling (the proposed std::Result) it is



[...]

 If you look at Rust Result<T, E>, it is basically a wrapped return
 value and the type in E must be known to the caller so cannot easily
 pass it up the chain. Type E can be anything but adding your own error
 types becomes cumbersome.


[...]

Thanks, that's exactly what I've been trying to say, except you said it
better. :-D

Error handling using sum types, etc., are at the core just a cosmetic
makeover of C's return codes.  It puts the onus on the caller to check
for every return code and take appropriate action. AND it's not easily
propagated up the call chain, because the error type E returned by func1
may not be the same type E returned by its caller, so you cannot simply
pass it along; you *have* to manually map it to your own error return
type.

In theory, your own error return type would be a sum type of all error
returns of the functions you call plus your own error codes. In
practice, I honestly doubt if anyone would bother doing this; I expect
the tendency would be to simply map every error from dependent functions
to the equivalent of INTERNAL_ERROR, i.e., a generic, non-descript,
unhelpful code that tells the caller nothing about what the actual error
is.

Basically, it would be identical to how you use error codes in C, except
dressed in prettier syntax.  The fundamental problems with C error code
handling remain unchanged.

For example, it does not address the issue that often, the information
required to decide how to handle an error is not readily available in
the caller, but can only be found higher up the call chain. The Rust way
is just glorified C return codes that doesn't solve this problem in any
way.


T

-- 
People demand freedom of speech to make up for the freedom of thought which
they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Feb 26 2022
parent reply __StarCanopy <starcanopy protonmail.com> writes:
On Saturday, 26 February 2022 at 23:56:31 UTC, H. S. Teoh wrote:

 In theory, your own error return type would be a sum type of 
 all error returns of the functions you call plus your own error 
 codes. In practice, I honestly doubt if anyone would bother 
 doing this


I tried to help alleviate this pain by creating a template that 
pipes a given sequence of functions, consolidating all possible 
types into a new result type.
```d
// Very contrived example
//          int, Outcome!(int, IsNegativeError), Outcome!(int, 
IsOddError)
chain!(() => -1,                     isPositive, isEven)()
     .handle!(
         num => text(num, " is an even, positive integer"),
         (IsNegativeError err) => text(err.num, " is a negative 
integer"),
         (IsOddError err) => text(err.num, " is an odd integer")
     ) // Outcome!(int, IsNegativeError, IsOddError)
     .writeln; // -1 is a negative integer
```
Feb 26 2022
parent __StarCanopy <starcanopy protonmail.com> writes:
On Sunday, 27 February 2022 at 04:57:28 UTC, __StarCanopy wrote:

     ) // Outcome!(int, IsNegativeError, IsOddError)


My apologies, the places of IsOddError and IsNegativeError should 
be reversed.
Feb 26 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2022 5:28 AM, Mike Parker wrote:

 I'll leave it to Walter to explain his 
 current thinking, as I can't recall what he's said about it.



https://digitalmars.com/d/archives/digitalmars/D/OT_-_C_exceptions_are_becoming_more_and_more_problematic_358395.html#N358446
Feb 24 2022
prev sibling parent Commander Zot <zot zot.zot> writes:
On Thursday, 24 February 2022 at 00:19:44 UTC, meta wrote:

 Support struct based exceptions (value type), passed on stack 
 (and hence RC support) as part of the return value of a 
 function.



 Who will allocates that (the RC part)?

 I personally disagree with the idea of exceptions altogether..


 The answer is in solutions like in Zig/Go, errors, multiple 
 return values, if changing the way error handling works in D, 
 better make it good, for good!


oh god, go code is so stupid to read b/c theres error handling 
everywhere mixed with code logic. i'm all for adding multiple 
return values, aka tuples, but exceptions are by far the best 
error handling method by readability. also you are forced to 
catch them and you got stack traces, which is super useful.


Zot
Feb 24 2022
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 23, 2022 at 02:26:41PM +0000, matheus via Digitalmars-d wrote:

 Just saw this today:
 
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html
 
 Seems relevant to any System Language like D that features Exceptions.


[...]

Quote:

	"The root cause is that the unwinder grabs a global mutex to
	protect the unwinding tables from concurrent changes from shared
	libraries. This has disastrous performance implications on
	today’s and upcoming machines."

Does D's unwinder grab a global mutex?


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves
neither. -- Slashdotter
Feb 23 2022
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 23 February 2022 at 14:26:41 UTC, matheus wrote:

 Just saw this today:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html

 Seems relevant to any System Language like D that features 
 Exceptions.

 Matheus.


This is an interesting paper, but I'm not sure where they are 
going with it.

Exception are expensive. They need to be used to handle 
unexpected things. That's kind of in the name. Things that happen 
often are not exceptional.

Pretty much all workaround they look at incur some performance 
penalty on the happy path, but this is not a bug, this is a 
feature. Exceptions are very cheap when not thrown, very 
expensive when thrown. This is what you want when handling a 
situation that is exceptional.

The perf they measure for std::expect would be worth 
investigating. Why is it slow?
Feb 23 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 23 February 2022 at 18:27:45 UTC, deadalnix wrote:

 On Wednesday, 23 February 2022 at 14:26:41 UTC, matheus wrote:

 Just saw this today:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html

 Seems relevant to any System Language like D that features 
 Exceptions.

 Matheus.


 This is an interesting paper, but I'm not sure where they are 
 going with it.

 Exception are expensive. They need to be used to handle 
 unexpected things. That's kind of in the name. Things that 
 happen often are not exceptional.

 Pretty much all workaround they look at incur some performance 
 penalty on the happy path, but this is not a bug, this is a 
 feature. Exceptions are very cheap when not thrown, very 
 expensive when thrown. This is what you want when handling a 
 situation that is exceptional.

 The perf they measure for std::expect would be worth 
 investigating. Why is it slow?


They aren't going anywhere, most of Herb's latest papers seem 
like ideas how the language could be improved upon, but beyond 
the original paper, presentation at CppCon and eventually some 
prototype available on Compiler Explorer, little more has 
happened.

I might be wrong here, but from C++ mailings it is clear nothing 
is happening with those papers.

Also in regards to exceptions, Bjarne has a paper where he 
criticizes the current compiler implementations for leaving 
performance improvements on the table by not wanting to break 
existing ABIs, while arguing against Herb's approach.

"C++ exceptions and alternatives"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf
Feb 24 2022
parent reply IGotD- <nise nise.com> writes:
On Thursday, 24 February 2022 at 08:08:49 UTC, Paulo Pinto wrote:

 They aren't going anywhere, most of Herb's latest papers seem 
 like ideas how the language could be improved upon, but beyond 
 the original paper, presentation at CppCon and eventually some 
 prototype available on Compiler Explorer, little more has 
 happened.

 I might be wrong here, but from C++ mailings it is clear 
 nothing is happening with those papers.

 Also in regards to exceptions, Bjarne has a paper where he 
 criticizes the current compiler implementations for leaving 
 performance improvements on the table by not wanting to break 
 existing ABIs, while arguing against Herb's approach.

 "C++ exceptions and alternatives"

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf


That's a problem for D because I suggest that we copy whatever 
C++ decides to implement. The reason is that the solution is 
probably going to be good enough for D. Using the C++ solution 
also ensures FFI compatibility. Associated with the new C++ error 
handling is going to be an ABI change (for every CPU 
architecture) and that the D project would create its own bespoke 
ABI is a lot of work which might not play well with C++ or other 
SW.
Feb 24 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 24 February 2022 at 10:06:24 UTC, IGotD- wrote:

 On Thursday, 24 February 2022 at 08:08:49 UTC, Paulo Pinto 
 wrote:

 They aren't going anywhere, most of Herb's latest papers seem 
 like ideas how the language could be improved upon, but beyond 
 the original paper, presentation at CppCon and eventually some 
 prototype available on Compiler Explorer, little more has 
 happened.

 I might be wrong here, but from C++ mailings it is clear 
 nothing is happening with those papers.

 Also in regards to exceptions, Bjarne has a paper where he 
 criticizes the current compiler implementations for leaving 
 performance improvements on the table by not wanting to break 
 existing ABIs, while arguing against Herb's approach.

 "C++ exceptions and alternatives"

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf


 That's a problem for D because I suggest that we copy whatever 
 C++ decides to implement. The reason is that the solution is 
 probably going to be good enough for D. Using the C++ solution 
 also ensures FFI compatibility. Associated with the new C++ 
 error handling is going to be an ABI change (for every CPU 
 architecture) and that the D project would create its own 
 bespoke ABI is a lot of work which might not play well with C++ 
 or other SW.


Until ISO C++26, ISO C++ is definitly not deciding anything 
related to Herb's proposal, and it remains to be seen if there 
will be anything in a form of a proper ISO C++ feature proposal 
paper for post ISO C++26.

Waiting for C++ to decide anything is only detrimental for D.
Feb 24 2022
prev sibling parent StarCanopy <starcanopy protonmail.com> writes:
After having built a result library on top of std.sumtype, and 
used it in some small programs, I have more appreciation for 
exceptions as its interface for error handling effects less 
clutter. And D's implementation could even be improved as shown 
by Adam's efforts and posts in this very thread. (Quite fond of 
rikki's ideas.)
Feb 23 2022