DIP77 - Fix unsafe RC pass by 'ref'

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 9 15:05:35 PDT 2015


On 4/9/2015 1:21 PM, deadalnix wrote:
> On Thursday, 9 April 2015 at 18:44:10 UTC, Walter Bright wrote:
>> On 4/9/2015 5:05 AM, Michel Fortin wrote:
>>> Why should it not have an opAssign marked @system?
>>
>> "Andrei's idea was to not do the copy for @system opAssign's, thus providing
>> C++ equivalence for those folks that need it and don't care about guaranteed
>> memory safety."
>>
>
> Why not bind this behavior to extern(C++) ?

Because the charter of @system is "the user supplies the memory safety", which 
fits here perfectly. extern(C++) carries a lot of other stuff with it.


> It is dangerous, at language level, to reason from usage instead of first
> principle (not that usage do not matter, usage should serve as a guideline for
> the principles) or thing like C++ templates happens.

On the other hand, throwing things in the language just because you can, with no 
idea what they are good for or how they will be used, doesn't end well.


>> My first impression is that's too complicated for the user to get right.
> Yeah, I don't think opPin is a the right way to go. It is always easy and
> tempting to add new stuff to make X or Y work, but at the end, it only create
> language complexity explosion.

Glad you agree. I'm afraid of making something that is technically correct, but 
unusable.


> There are some inefficiencies involved here, but I trust the compiler to be able
> to optimize it away for the most part, and we have a backdoor for thoses who
> want to bypass safety.

Yes. Interestingly, this is a superset of what Rust does. Rust's has the idea of 
only one mutable reference at a time, for efficiency. As the DIP points out, if 
the function only has const references available other than the one mutable one, 
it doesn't do the copy, either.

I was curious how Rust handled the global variable issue. Turns out it doesn't - 
mutable global variables are marked as "unsafe" and the checker gives up on it.


> More generally, this is why I oppose the return attribute + adding op on
> reference type in favor of a principle scope proposal. The first one is 2
> language features for a less general end result.

I understand where you're coming from on this. The design was picked for being 
as simple as possible with the least disruption.


More information about the Digitalmars-d mailing list