Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jonathan M Davis]

On Wednesday, March 21, 2018 19:50:52 Jack Stouffer via Digitalmars-d wrote:
> On Wednesday, 21 March 2018 at 18:50:59 UTC, Jonathan M Davis
>
> wrote:
> > The struct being returned would need to be marked with scope
> > (or its members marked with scope) such that the compiler
> > treated the result as containing values from the function
> > arguments. I don't know whether that's possible with DIP 1000
> > as-is
>
> Not as far as I can tell. Marking it as scope in the function
> body means it can't be returned, and marking the array in
> GetoptResult as scope results in a syntax error.
>
> > In this particular case, it may make more sense to just let
> > getopt be @safe on its own and just let the caller mark all of
> > the uses of & as @trusted.
>
> This is thankfully the case currently.
>
> > If it's possible to mark GetoptResult with scope such that we
> > can use scope without copying, then great, but if it's not,
> > then I'm inclined to argue that we should just make sure that
> > getopt itself is @safe and not worry about whether the caller
> > is doing anything @system to call getopt or not.
> >
> > Regardless, this does raise a potential issue with scope and
> > user-defined return types, and we should explore how possible
> > it is for DIP 1000 to solve that problem without forcing copies
> > that wouldn't be necessary in @system code.
>
> My cause for alarm with this limitation is this is one of the
> issues (taking address of locals safely) that DIP1000 was
> designed to solve. If, in practice, DIP1000 code can't be used
> for this case when the code become sufficiently complex, then we
> have a real problem on our hands.

Well, it certainly looks like once user-defined types are being returned,
DIP 1000 falls short. And even if it were improved to allow for member
variables to be marked with scope such that the compiler allowed for
arguments to escape via a return value (which may or may not make sense with
how DIP 1000 works), we then have the problem with potentially needing to
copy the member variables (or the entire struct) in the caller - either that
or to cast and have it be @trusted. I don't know how a big a problem this is
really going to be in practice, but it certainly shows that DIP 1000 isn't a
silver bullet.

- Jonathan M Davis