[Dlang-internal] DIP1000 discussion and testing: RC pointer snippet

Walter Bright via Dlang-internal dlang-internal at puremagic.com
Thu Oct 20 14:43:59 PDT 2016


On 10/20/2016 9:32 AM, Dicebot wrote:
> On 10/16/2016 11:15 PM, Walter Bright wrote:
>> On 10/16/2016 1:03 PM, Dicebot wrote:
>>> Where does it come from?
>>
>> It comes from trying to compile code with the new safety checks, and
>> having it fail to compile and require adding annotations all over the
>> place. The idea is to infer such annotations in the obvious places.
>> 'return' was already successfully inferred in many places, this just
>> extends an existing practice.
>>
>>
>>> I don't see any mention of such deduction in
>>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>>
>> It's one of those things that becomes necessary once trying to implement
>> it.
>
> Walter, there is no way we can merge your PR if it implements things not
> mentioned in DIP. If you don't want to spend time adjusting it yourself,
> please, at least notify me about what has changed. That will save both
> of us a lot of time.

Ok. But it's pretty simple. A local variable that is initialized with a scoped 
value is tagged with scope.


>> Inferring 'scope' and 'return' as much as possible makes @safe much more
>> palatable. All I can say is try to break it!
>
> It also makes reasoning about what your code does much harder, adding
> unacceptable amount of magic to it. I'd much prefer to rely on `auto`
> and fix rest of cases myself through deprecations than go with current
> "helpful" behavior.
>
> Such semantics are also unprecedented in D as far as I can remember.
> Before storage classes would never be inferred for variables with
> explicit type. That is highly confusing.

It's already done by DIP25, and D has been very successful in inferring @safe, 
@trusted, @system, pure, @nogc, and nothrow. I'd like to go even further and 
infer const, but that's a more complex task.


> Right now I think this is a bad decision and should be reconsidered.
> Would like to now what other developers thing though.

It's long been my belief that if lifetime annotations had to be explicit, few 
would be interested in using such a "bondage and discipline" language. As 
further evidence of that, Rust goes to great lengths to infer lifetime 
attributes. Annotations don't excite people.




More information about the Dlang-internal mailing list