November 23, 2020
On Monday, 23 November 2020 at 03:39:21 UTC, Timon Gehr wrote:

> scope c = longer(a,b);

Thanks! This works indeed, and makes sense.
November 25, 2020
On 11/23/2020 3:17 AM, IGotD- wrote:
> In the presentation you basically did a copy of the single ownership in Rust. In the function we assign nameLookup and idLookup with a borrowed pointer but not as owners. This currently compiles

It shouldn't as nameLookup and idLoopup are globals. Looks like you found a bug!

> but your presentation I get the impression that you are going to put D under full single ownership lockdown.

Sorry if I gave that impression. It will only be so at your discretion with where you place @live.
November 25, 2020
On 11/22/2020 3:38 AM, ag0aep6g wrote:
> So far, DIP1000 is not a success. It's buggy, poorly documented, hard to understand.
> Phobos only compiles with -preview=dip1000 by relying on accepts-invalid bugs.

I've already talked about the documentation being inadequate.

As for the rest, when saying such things please include a list of bugzilla issues. If you know of issues that are not in bugzilla, please add them.

November 25, 2020
On 11/22/2020 3:08 AM, Dibyendu Majumdar wrote:
> Hi Walter, are you aware of the explicit lifetime annotation facility in Rust?

Yes, and that was part of the discussion.


> This seems critical to allow correct lifetime calculations in a graph of objects.
> 
> I read in DIP1000 that there is an automatic lifetime calculation when 'scope' storage class is used? However does that work with nested object graphs?
> 
> Rust had to have explicit annotations I believe as automated calculations are not sufficient.

I recall the examples given for why explicit annotations were needed were insufficiently compelling.

But we'll see how things unfold.
November 25, 2020
On 11/22/2020 3:14 AM, Dibyendu Majumdar wrote:
> @live is more complicated I suppose as it can't deal with GC pointers?

It's not that it can't deal with them. It's that it treats them as any other pointer.

Adding a type constructor that says "this pointer is a GC pointer" is a major escalation in complexity of the language. Other languages have done it (see Microsoft's "Managed C++") but I don't think it caught on because I haven't heard much about it in years.

November 25, 2020
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.

November 26, 2020
On Wednesday, 25 November 2020 at 10:51:12 UTC, Walter Bright wrote:
> On 11/22/2020 3:14 AM, Dibyendu Majumdar wrote:
>> @live is more complicated I suppose as it can't deal with GC pointers?
>
> It's not that it can't deal with them. It's that it treats them as any other pointer.

As what kind of other pointer? I quess `new int()` returns a pointer that is treated as `return scope`, right?
November 26, 2020
On Wednesday, 25 November 2020 at 10:51:12 UTC, Walter Bright wrote:
> Other languages have done it (see Microsoft's "Managed C++") but I don't think it caught on because I haven't heard much about it in years.

Yes, it was called VC++, there were 2-3 versions to try and jump start it. Eventually it was replaced by a completely native C++ header file using modern C++ with smart pointers instead of a GC to communicate with COM objects.

The C++ header implementation hasn't seen any major developments but it is still their recommended way of interfacing. By the looks of it they are focusing more on Rust and seem to be cutting out C++ altogether.

November 25, 2020
On 11/25/2020 8:42 PM, Dukc wrote:
> On Wednesday, 25 November 2020 at 10:51:12 UTC, Walter Bright wrote:
>> On 11/22/2020 3:14 AM, Dibyendu Majumdar wrote:
>>> @live is more complicated I suppose as it can't deal with GC pointers?
>>
>> It's not that it can't deal with them. It's that it treats them as any other pointer.
> 
> As what kind of other pointer? I quess `new int()` returns a pointer that is treated as `return scope`, right?

No, it returns `int*`.
November 26, 2020
On Thursday, 26 November 2020 at 05:24:22 UTC, Gordan wrote:
> On Wednesday, 25 November 2020 at 10:51:12 UTC, Walter Bright wrote:
>> Other languages have done it (see Microsoft's "Managed C++") but I don't think it caught on because I haven't heard much about it in years.
>
> Yes, it was called VC++, there were 2-3 versions to try and jump start it. Eventually it was replaced by a completely native C++ header file using modern C++ with smart pointers instead of a GC to communicate with COM objects.
>
> The C++ header implementation hasn't seen any major developments but it is still their recommended way of interfacing. By the looks of it they are focusing more on Rust and seem to be cutting out C++ altogether.

You mean C++/CX, which was replaced by C++/WinRT.

C++/CLI, the .NET variant is alive and doing quite well as more productive way to interface with native code than doing a bunch of P/Invoke declarations all over the place.

As for C++/WinRT, unless we are talking about Windows dev team members used to write code with Windows Runtime Library previously, the large majority of UWP devs is quite pissed off with C++/WinRT, because Windows dev team has thrown it at us without any consideration for providing a Visual Studio experience comparable to C++/CX. So you are left editing IDL files without any kind of editor experience, and every time wrappers are generated by cppwinrt compiler, you need to manually copy and merge the outcome.

Wait for ISO C++ to reach feature parity with C++/CX in metadata and reflection capabilities they say.

COM libraries approach has always been header files generated out of COM type libraries (.tlb) or now with the UWP/WinRT related improvements, .NET Metadata files (.winmd).

Also to have a good performance in Release/AddRef calls versus .NET GC, C++/WinRT makes use of background threads for disposal, stack allocation of handles for COM/UWP references and constexpr generation of metadata.