@live questions

[IGotD-]

On Wednesday, 25 November 2020 at 10:42:02 UTC, Walter Bright 
wrote:
>
> 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.


struct MyStruct
{
	int s;
}


struct LookUp
{
	@live void addStruct(MyStruct* s, const string name, int id)
	{
		nameLookup[name] = s;
		idLookup[id] = s;
	}
private:
	MyStruct*[string] nameLookup;
	MyStruct*[int] idLookup;
}


void main()
{
	MyStruct* s = new MyStruct;
	LookUp l;

	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.