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.

That raises the question what method is going to replace exceptions in that case?
Will D introduce an alternative method of error handler that plays better with @live?

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.

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.

Only with inter-procedural dataflow anlysis.
Since @live's DFA if intra-procedural (does not the leave function body) it cannot model dataflow that may be continued in another functions frame.
then again ... perhaps that's not actually and issue, but I haven't thought much about it.

On Wednesday, 25 November 2020 at 11:05:06 UTC, Stefan Koch wrote:
> 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.
>
> Only with inter-procedural dataflow anlysis.
> Since @live's DFA if intra-procedural (does not the leave function body) it cannot model dataflow that may be continued in another functions frame.
> then again ... perhaps that's not actually and issue, but I haven't thought much about it.

I think you can do make worst case assumptions, but D should do context senditive analysis. Basically, compile summaries (what can it throw) for all functions before doing the live analysis. It is common to do overapproximations (assume too much, but compute fast).

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.
>
> That raises the question what method is going to replace exceptions in that case?
> Will D introduce an alternative method of error handler that plays better with @live?

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.

Go allows an optional return slot for an Error value that you are not forced to check, as is typical for Go's approach of choosing the worst possible option, but at least it's a slight improvement on C. Get used to writing `if err != nil` every other line.

I think Nim actually does have exceptions.

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.

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.

@live needs context sensitive analysis to get better precision as it tries to match up malloc with free if my understanding is correct. So it needs to know what exceptions can occur at each function call.

You could also extend @live and make it more useful with global flow typing of allocation source (gc vs malloc). For that you need inter procedural analysis.

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.

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.

Maybe he is Go developer :o)

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.
>
> That raises the question what method is going to replace exceptions in that case?
> Will D introduce an alternative method of error handler that plays better with @live?

A (library-based) sum type used as error value, probably. That's what Rust does, except it also has language support for the concept. Because I personally don't like exceptions much, I have some experience from that approach (using TaggedAlgebraic). It feels somewhat cumbersome - Rust probably is better fit for that than we are. But D still can do more tricks C++, Java or C# can, probably. `with` and `final switch` statements are useful in my experience. As is the possibility to `sumTypeVariable.visit!(...)`, but it has the downside that you always exit that statement the same way -you can't `break` or `goto` out.

Why I don't like exceptions? I feel I am making my functions 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.