On Wednesday, 18 February 2015 at 20:25:07 UTC, Dicebot wrote:
> On Wednesday, 18 February 2015 at 18:26:34 UTC, deadalnix wrote:
>> On Wednesday, 18 February 2015 at 14:46:30 UTC, Dicebot wrote:
>>> From my POV best proposal from last lengthy discussion was to enable reference-counted non-gc-heap Exceptions. But that needs a language change because RefCounted!T is a struct and thus neither can be thrown nor can be part of Throwable class hierarchy.
>>>
>>
>> This is not satisfactory. First there is no safe way to refcount right now. Second, this has all kind of implication for the GC to scan the heap and so on. Finally this do not solve the type qualifier problem.
>>
>> I don't think a language change to do this pay for itself. i understand the appeal, as this is probably simpler to implement than the alternative, but that is really building technical debt.
>
> Right now I don't care for full memory safety or type safety of any proposed solution. I will be glad to have any that actually works - and I have not heard of any idea that allows to do that without language changes. Your push for owned is also hardly relevant because exceptions are good examples of data with shared / non-determenistic ownership and thus won't benefit from it.

Non-deterministic ownership is exactly what the owned concept helps with, because it allows to delay deciding on an actual management mechanism until it reaches the consumer. When someone catches an owned exception, they can then choose to store it in a non-owned variable (=> making it GC owned), in a ref-counted (which then takes ownership), or to not store it at all, in which case it will get released automatically when the catch block is left. Before that decision is made, it can still be used without losing the "owned" property, by passing it as a scope parameter (or storing it in a scope variable).

On Wednesday, 18 February 2015 at 20:47:36 UTC, deadalnix wrote:
> On Wednesday, 18 February 2015 at 20:25:07 UTC, Dicebot wrote:
>> Right now I don't care for full memory safety or type safety of any proposed solution. I will be glad to have any that actually works - and I have not heard of any idea that allows to do that without language changes. Your push for owned is also hardly relevant because exceptions are good examples of data with shared / non-determenistic ownership and thus won't benefit from it.
>
> I think it make sense to require that something thrown to be owned. That means ownership can be transferred from one thread to the other. That also mean that the compiler can free the exception when it goes out of scope, which is what is wanted for exception and @nogc to work together.
>
> The invalid operation in @nogc would become promoting owned to Tl/shared/immutable rather than not allocating at all.
>
> This has added benefit to allow for way more code to be @nogc, and in many cases transfers the GCness of something in the caller, which makes for @nogc compatible libraries that can be used in both @nogc and gc situation.
>
> If we are gonna add something in the language, it'd better be worth it.

+1

Could you take the time to make a concrete proposal? I'll try to have another go at `scope`, which is of course deeply linked with ownership, and these two things need to work well together. I want to avoid proposing something that will later collide with your ideas.

On Tuesday, 17 February 2015 at 19:03:49 UTC, Chris Williams wrote:
> Every throwable function call could be assumed to have a typed result (even void functions) and if, after the return, the caller checks the type and detects that it was an error, bubbles that up, then eventually you get to wherever the catcher is.
>
> But so basically, the current ABI doesn't support it and there's no desire to change it? How do exceptions currently happen, if not via some official ABI declaration of how throwable methods interact with one another? The compiler/linker determines where the catcher is and inserts code to cut down the stack and perform a long jump all the way back? If so, how do scope statements work?

No problem. in fact this kind of solution is a good fit for language where try blocks are rare (say OCaml for instance) as you can unwind much faster, while keeping the cost on the fast path small.

But that wouldn't be a good fit for D (or even worse for C++) because you have unwinding going on (destructor, scope statements, ...) which makes for a lot of implicit try blocks.