Go, D, and the GC

[Dmitry Olshansky via Digitalmars-d]

On 05-Oct-2015 12:33, Shachar Shemesh wrote:
> On 05/10/15 10:49, Dmitry Olshansky wrote:
>
>>
>> Yes and no, if your type is movable in C++ you have to have a T.init
>> equivalent to leave something behind after move (oops!).
> No, under C++ you can choose whether it makes sense for your type to be
> movable or not.

IF you need a movable type. Most types these days ought to be movable to 
be fast. So it's OOPS after all. e.g. vector<T> is movable hence it has 
T.init.
*Everything non-trivial* in STL now has T.init, including the unique_ptr 
and shared_ptr.

The T.init is hidden somewhat:

auto a = unique_ptr<int>(new int);
auto b = move(a);
// now a is unique_ptr<int>.init that is null

Same goes for locks, threads and whatnot.
My point is: if it can move, it has T.init.

Copyable types that are not movable are a minority IMO.

Non-movable were described in the snipped part of my message.

> No oops at all.
>
> C++ does not make any attempt to protect you from your own incompetence.

Sadly it goes to great lengths to prove your own incompetence. 
Eventually it does, but that is OT.

> Within that assumption (which some people accept as reasonable and
> others don't), C++ does the right thing.

If I got you right you seem to imply that types that are copyable but 
not movable are a good thing. I humbly disagree.

-- 
Dmitry Olshansky