Release D 2.073.0

Olivier FAURE via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Sat Jan 28 06:56:17 PST 2017


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.


More information about the Digitalmars-d-announce mailing list