13-Nov-2014 00:27, deadalnix пишет:
On Wednesday, 12 November 2014 at 20:36:32 UTC, Dmitry Olshansky wrote:
Seems sane. owned(Exception) would be implicitly assumed i.e.:
catch(Exception e){ ... }

would be seen by compiler as:
catch(owned(Exception) e){ ... }

What happens if I throw l-value exception? Do I need to cast or
assumeOwned it?

It's easy to see how it goes with r-values, such as new
Exception(...), since they are "unique expressions" whatever that
means ;)


Yes, the unsafe road must always be open, we are a system programming
language :)

I take it that owned(T) is implicitly deduced by compiler in case of
pure functions? Also it seem templates should not take owned(T) into
consideration and let it decay... How does owned compose with other
qualifiers?


You mean what is I have an owned field into an object ? In the case you
pass the owned where a TL, shared or immutable is expected, the island
is merged so the question do not make sense.

Sorry, forgot to reply.

Here is the case I wanted to check:

try{
        ...
}
catch(owned(Exception) e){
        foo(e);
}

void foo(T)(T arg){
        // what would this print? Exception or owned(Exception)
        // do we bloat a bit more on qualifiers?
        pragma(msg, T);
}



An owned field in an object is interpreted as follow:
  - immutable => immutable
  - shared => owned (and can be touched only if the shared object is
synchronized, which allow to hide a whole hierarchy behind a mutex. That
is another selling point but I don't wanted to get into all the details
as the post was already quite big).
  - const => const owned (essentially unusable - except via burrowing if
we ever want to go that road one day).


Thanks, looks sane.

Seems absolutely cool. But doesn't allocating exception touches heap
anyway? I take it that if I don't save exception explicitly anywhere
the owned island is destroyed at catch scope?


Yes it touches the heap. But as long as things are owned, they'll be
freed automatically when going out of scope. That means, with that
definition of things, what is forbidden in @nogc code is to consume the
owned in such a fashion that its island is merged into TL, shared or
immutable heap. If you don't do this, then your isolated will be freed
when going out of scope and the GC won't need to kick in/no garbage will
be produced.

Doing so allow for relaxing the constraint in @nogc and allow for the
same library code to be used with or without GC.


--
Dmitry Olshansky

Reply via email to