On Thursday, 26 November 2020 at 00:23:01 UTC, Meta wrote:
> On Wednesday, 25 November 2020 at 23:23:17 UTC, Araq wrote:
>> On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:
>>> I think Nim actually does have exceptions.
>>
>> Correct and the one of the "deterministic" kind (check after function calls that can raise). It doesn't require "inter-procedural dataflow anlysis" either but hey, what do I know, have fun in your nonscientific bubble.
>
> I don't understand the hostility. What did I say that was "unscientific"? For that matter, I didn't say anything about interprocedural analysis.

He is the Nim author. :)

But, @live tries to do things that is better done through the type system and RAII.
To make RAII work you need exceptions. Removing them would be a disaster. What is wrong with make_unique?

The time complexity to do it without type system constraints will most likely make @live underwhelming or slow down compilation significantly.

Why encourage using malloc directly in the first place?

To get @safe ARC, D needs a global borrow checker to prevent dangling interior pointers. Without it, D will be stuck with a heavyhanded GC for all @safe code.

On Thursday, 26 November 2020 at 04:41:57 UTC, Dukc wrote:
> less general when using them. For example, when parsing XML and encountering a syntax error, if I throw on the error I essentially declare that my function is only intended for generally sound XML -it isn't intended to count or list syntax errors in a text full of them. Errors in return codes are use case agnostic in this regard. Perhaps this is one of the reasons why Walter considers exceptions an aged concept.

Provide a templated object for custom error tracking and return a pointer to it wrapped as an exception.

That would be the most general approach.

On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:

> This is well-trodden ground among D's competitors.
>
> Rust has no exceptions (only `panic`, which aborts the current thread), and instead opts to use algebraic data types along with some light language support. Swift does something very similar.

No, Swift has dedicated syntax for error handling, just like D. The syntax looks very much like the syntax used for exceptions. The implementation doesn't use table based exceptions but instead builds on the Objective-C/Cocoa error handling style. Which is to return a bool to indicate success or failure and return the actual error through an out parameter. Any thing that is thrown need to implement the `Error` protocol. Which probably means that there is some for of type info used under the hood.

Zig uses a form of algebraic data type to return a value or an error. An error is represented as an error set, kind of like an enum. Zig provides syntax sugar on top this, which syntax looking very much like exceptions. The error handling in Zig looks pretty good, the only problem is that you can only throw error codes. It's not possible to provide any extra data with an error.

--
/Jacob Carlborg

On Wednesday, 25 November 2020 at 17:15:14 UTC, Meta wrote:
> Rust has no exceptions (only `panic`, which aborts the current thread), and instead opts to use algebraic data types along with some light language support. Swift does something very similar.

Worth mentioning that the default behaviour for Rust's `panic` is to unwind the stack.  This means that panics are recoverable errors in practice (e.g. the Tokio task-scheduling framework will gracefully handle panics inside individual tasks).

IIRC libraries can specify in their build config if they rely on the stack-unwinding behaviour, so that builds will fail if a downstream requests the abort option (or vice versa).  I believe though that even in the abort case, the parent thread may still be able to catch and recover from an aborted child thread.  See e.g.:
https://doc.rust-lang.org/nomicon/unwinding.html

So it's less that Rust has no exceptions, more that they don't _call_ them exceptions, they are not conceptualized as "this is allowed to fail", they don't distinguish different types of such error, and depending on the build config the circumstances in which they are recoverable are more or less constrained.

On Friday, 27 November 2020 at 12:52:37 UTC, Joseph Rushton Wakeling wrote:
>
> IIRC libraries can specify in their build config if they rely on the stack-unwinding behaviour, so that builds will fail if a downstream requests the abort option (or vice versa).  I believe though that even in the abort case, the parent thread may still be able to catch and recover from an aborted child thread.  See e.g.:
> https://doc.rust-lang.org/nomicon/unwinding.html
>
> So it's less that Rust has no exceptions, more that they don't _call_ them exceptions, they are not conceptualized as "this is allowed to fail", they don't distinguish different types of such error, and depending on the build config the circumstances in which they are recoverable are more or less constrained.

Does this mean that Rust is dependent on libunwind despite its non exception like error handling?

On Friday, 27 November 2020 at 19:33:32 UTC, IGotD- wrote:
> Does this mean that Rust is dependent on libunwind despite its non exception like error handling?

Mixing languages is undefined behaviour... So, probably not?

On Friday, 27 November 2020 at 19:36:50 UTC, Ola Fosheim Grostad wrote:
>
> Mixing languages is undefined behaviour... So, probably not?

Unwinding isn't really connected to any language. It is a part of the CPU architecture runtime ABI even if it might be partially implemented in C or C++. Several languages glue to this ABI in order to implement their stack unwinding.

On Friday, 27 November 2020 at 19:42:01 UTC, IGotD- wrote:
> On Friday, 27 November 2020 at 19:36:50 UTC, Ola Fosheim Grostad wrote:
>>
>> Mixing languages is undefined behaviour... So, probably not?
>
> Unwinding isn't really connected to any language. It is a part of the CPU architecture runtime ABI even if it might be partially implemented in C or C++. Several languages glue to

Not portable. According to the docs, UB for Rust.

On Friday, 27 November 2020 at 19:42:01 UTC, IGotD- wrote:
> On Friday, 27 November 2020 at 19:36:50 UTC, Ola Fosheim Grostad wrote:
>>
>> Mixing languages is undefined behaviour... So, probably not?
>
> Unwinding isn't really connected to any language. It is a part of the CPU architecture runtime ABI even if it might be partially implemented in C or C++. Several languages glue to this ABI in order to implement their stack unwinding.

Just saw a pullrequest that does suggest that they use the regular libunwind as they argued about the license. But the docs still says that you need to catch errors at FFI boundaries.

On Sunday, 22 November 2020 at 00:09:36 UTC, Ola Fosheim Grostad wrote:
> On Saturday, 21 November 2020 at 23:05:19 UTC, IGotD- wrote:
>> I reacted to the comment of Walter Bright about exceptions in the "Destroy All Memory Corruption" presentation. The point he made that exceptions don't play well with compile time data flow analysis. He also mentioned that he thinks that exception will become obsolete in the future. Exceptions are used in many languages today and even the newest ones so I can't see a trend here.
>
> Exceptions can be modelled with conditionals in static analysis. They should work out ok with dataflow analysis.

Many conditions to check before jumping, and then you still run the risk of some denial. Often everything looks good and ready to work, and even then it can give some unknown error. Could the entire thread stop working due to a minor error that could be tried again?