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.
