Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jack Stouffer]

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.