On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote:
If you've got a case, make it. If you see problems, explain. If
you want to help, please do.
For what it's worth, here are my problems with 'return scope':
- As far as I can tell, it's not properly documented. The github
page for DIP-1000 is apparently pending a rewrite, and I can't
find a formal definition of 'return scope' anywhere (the D
reference 'Functions' page only mentions 'return ref', and in
passing).
- I personally don't like using the return keyword as anything
but an instruction; when I'm reading code, I can have a good
feeling of the code's flow by just looking at the indentation,
the if/while/for blocks, and the break/throw/return instructions.
I'll be the first to admit it's kind of minor though.
- It's an obvious monkey patch, and it will clearly have to be
replaced at some point. It only addresses cases where a reference
might be escaped through a single return value; it doesn't
address escaping through 'out' parameters, or through a returned
tuple.
- It fails to enable useful features like the swap function, or
storing a scoped value in a container (well, outside of @trusted
code, but that's beside the point).
- Because it isn't an integral part of the type system, but more
of an external addition, it has a ton of special cases and little
gotcha's when you try to do something complex with it. (ref
parameters can't be scope, can't have pointers on scope values,
which means you can't pass any kind of scope value by reference,
you can't have scope types as template parameters, etc)
The two last ones feel like the most important problems to me. If
all you want to do is variants of the identity function, and
returning references to attributes, then return ref and return
scope is everything you need (arguably). If you want to store
containers of scoped values, swap scope values, and generally
treat scope as a first-class citizen, then return scope and
return ref seem like a step in the wrong direction.
The meta problem people seem to have with 'return scope' seems
more of a social problem. Apparently a lot of people feel like
you haven't treated their concerns seriously; part of it is that
as far as I'm aware there hasn't been a proper, open
brainstorming on how to address lifetime analysis in D.
My reading of the situation, which may be completely off-base, is
that you took inspiration from Marc Schütz's proposal, and wrote
something simpler, easier to understand and to code with, and
following the model you developed when coming up with inout (no
templates, KISS, don't use up too much language complexity estate
on an optional feature), then entered a cycle of gradually
improving it, eventually making DIP-1000.
People who don't like the direction DIP-1000 goes towards are
upset because they feel way too much effort is going towards
refining an idea they don't agree with in the first place. To
speak bluntly, I don't think you've addressed their concerns at
all, and I hope you do so before 'scope return' is set in stone.
So, do what numerous people have done numerous times already,
to no great effect?
Please don't be hostile. When you have a communication problem,
being passive-aggressive will only makes it worse.
