On Tuesday, 24 February 2015 at 12:44:54 UTC, Marc Schütz wrote:
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei
Alexandrescu wrote:
On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
<schue...@gmx.net>" wrote:
These two points have undesirable consequences: All consumers
such
objects need to be aware of the exact type, which includes the
management strategy (RC, Unique, GC). But this is a violation
of the
principle of separation of concerns: a consumer shouldn't
need to have
information about the management strategy, it should work
equally with
`RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it
doesn't take
ownership of the resource.
Well I don't know of another way.
Ok, I wrote my reply assuming that you are aware of the various
proposals deadalnix, myself and several other people have made
in the past, some of them quite specific. But now that I think
of it, I don't remember that you were ever directly referring
to it in any of your posts. Maybe you just missed it?
As one example, here is what I originally suggested:
http://wiki.dlang.org/User:Schuetzm/scope
It's not completely up to date, during discussions I gained
many useful new insights to simplify it and make things more
consistent. It's also part of a bigger picture (deadalnix's
ideas about ownership play an important role, too), which
unfortunately isn't easy to recognize, because this page has
become quite large und unwieldy. I should make a post
explaining this.
I'm working on my own idea now. I make scope transitive, because
it's both memory safe and simple to implement, but doing so may
cause some things which are actually safe to be considered unsafe
(but then you could just use @system blocks or @trusted lambdas
to correct this). Also, I don't think `scope` needs to be part of
the type.
I'm about 90 percent sure, 10 percent unsure that my system will
work. I'll have it soon enough. It needs DIP25 to be expanded to
all reference types (not just `ref`), requires my own DIP71,
http://wiki.dlang.org/DIP71 for total safety, and possibly one or
two more additions for a reliable ownership. The only real cost
is added complexity to function signatures (a la DIP25), which
can and should be inferred in most cases, assuming we aren't
crippled by an ancient and subpar linking mechanism which
requires all this manual marking of signatures all the time.
Stay tuned, sir!
