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!

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?

BTW, the application here is a design that Dicebot and I have been discussing since DConf 2015 to address the concerns related to range implementations of random number generation and random algorithms.
  • 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

Reply via email to