nise at nise.com
Wed Nov 25 11:18:24 UTC 2020
On Wednesday, 25 November 2020 at 10:42:02 UTC, Walter Bright
> It shouldn't as nameLookup and idLoopup are globals. Looks like
> you found a bug!
> Sorry if I gave that impression. It will only be so at your
> discretion with where you place @live.
Yes, but you get the idea. If I would put nameLookup and idLookup
in a struct for example which is usually the case, then I'm not
sure what applies.
@live void addStruct(MyStruct* s, const string name, int id)
nameLookup[name] = s;
idLookup[id] = s;
MyStruct* s = new MyStruct;
l.addStruct(s, "id1", 1);
Putting nameLookup and idLoopup in a struct also works with the
DIP1000 preview which contradicts you presentation but I guess
this is only a prototype. If I'm going to interpret your
presentation, then an assignment of a pointer is a move with
change of ownership just like Rust. Then you mention in this
thread that you want to make @live default, and this really
worries me. Basically forced single ownership makes the common
design pattern in the example above impossible and this is
something people who use Rust must battle all the time (I guess
they just use reference counted objects which is GC).
If want to implement lifetime analysis then you need to go the
full way which includes single ownership otherwise it isn't
solvable. A half variant, the question is here is how useful such
implementation would be. One possibility is that you make
functions the barrier where the data flow analysis works, so
addStruct would not be allowed to be @live and inside that
function is "do whatever you want" territory. This of course
contradicts making @live default.
More information about the Digitalmars-d