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.

Reply via email to