On 8/13/2016 1:13 AM, Joseph Rushton Wakeling wrote:
On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote:
That's just what this DIP addresses.

    struct MyWrapperStruct (T)
    {
        private T* data;

        public this (ref T input)
        {
            this.data = &input; // error: not allowed to take address of ref
variable
        }
    }

The DIP does not add ownership annotations or semantics.

Unless I've misunderstood you, that doesn't address my use-case -- it outright
bans it!

Taking the address of a ref variable has not been allowed in @safe code for a long time.


The above code is unsafe only if the lifetime of `data` outlives the lifetime of
`input`.  Surely the new scope rules should be able to distinguish the cases?
If that's already envisioned, how would that work?

That depends on how the instance of MyWrapperStruct is allocated. How did you intend to allocate it?

  • Re: DIP1000: Scoped Poi... Joseph Rushton Wakeling via Digitalmars-d-announce
    • Re: DIP1000: Scope... Joseph Rushton Wakeling via Digitalmars-d-announce
    • Re: DIP1000: Scope... Walter Bright via Digitalmars-d-announce
      • Re: DIP1000: S... Joseph Rushton Wakeling via Digitalmars-d-announce
        • Re: DIP100... Walter Bright via Digitalmars-d-announce
          • Re: DI... Joseph Rushton Wakeling via Digitalmars-d-announce
            • R... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Walter Bright via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Walter Bright via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Walter Bright via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Walter Bright via Digitalmars-d-announce
              • ... Guillaume Chatelet via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Walter Bright via Digitalmars-d-announce
              • ... Mike via Digitalmars-d-announce
              • ... Walter Bright via Digitalmars-d-announce
              • ... Mike via Digitalmars-d-announce

Reply via email to