Alternatives to exceptions for error handling

[Adam D. Ruppe]

On Monday, 23 November 2020 at 02:14:33 UTC, Vladimir Panteleev 
wrote:
> Some valid patterns were affected though, such as returning 
> `this` (as in the builder pattern). Perhaps it would make more 
> sense to instead allow annotating functions as that it's safe 
> to discard their return value (@discardable or such)?

That might work. I also frequently return values on setters and 
that might get tricky as well.

@property int foo(int v) { return this.v = v; }

that kind of thing.

@discardable would be possible there too.

But then there's also generic forwarders:

struct Wrapped(T) {
     T t;
     auto opDispatch(string name, Args...)() { return 
t[name](args); }
}

you know. And if it wraps one of those builder style things, it 
should probably inherit the discardable.... but that's a big 
complication.

Odds are I'd actually just mark the whole wrapped thing 
@discardable anyway.

(and we can say this same thing about @nodiscard, but I think it 
is less important to forward that since it at least still 
compiles if it is not there.)


There's also some common C functions that could get annoying. 
memcpy, for example, unconditionally returns the destination 
pointer you passed in. Obviously we could just mark the binding 
@discardable too.


I currently lean toward @nodiscard as being easier to use but I 
do expect @discardable would work pretty well too, just with a 
more involved transition period.