Simplify overlap

[andralex]

Related: http://forum.dlang.org/post/ner843$2cag$1@digitalmars.com but this is an improvement regardless of one's opinion of inout.

[schveiguy]

removing inout doesn't require using std.algorithm.max/min instead of internal versions. See same thread.

Edit: said that backwards. Using std.algorithm.min/max doesn't require removing inout.

[9il]

please add more detailed import

[andralex]

@9il good point - done

[DmitryOlshansky]

LGTM
@andralex to merge or not ? If inout is about to leave us, then let's merge.

[wilzbach]

@andralex to merge or not ? If inout is about to leave us, then let's merge.

From the discussion

I know of no "better" idioms, in terms of code generation and
specificity, to replace inout (or at least, inout as I envision it
should be). Care to elaborate?
I thought I did. Use one-liner functions that forward to templates.

Btw did anyone already point out that with inout the return type is inout(T)[] not auto?

[schveiguy]

I don't want to say that this is extremely important to keep the way it is: we can remove inout from this function, and we pretty much gain nothing and lose compiler protection from mutation, but it's not super-harmful in this instance. I just think this is kind of a waste of time to make this minor change. If we are getting rid of inout, that decision hasn't been publicly announced, and we should at least wait until the path forward for those who depend on it is sorted.

Btw did anyone already point out that with inout the return type is inout(T)[] not auto?

You can change the inout version to return auto. Again, no need to remove inout.

[quickfur]

We're killing inout? When was this decision made? Where's the forum thread / announcement?

[JackStouffer]

We're killing inout? When was this decision made? Where's the forum thread / announcement?

@quickfur Andrei really wants to. See http://forum.dlang.org/thread/nepm2k$311l$1@digitalmars.com http://forum.dlang.org/thread/ner843$2cag$1@digitalmars.com and http://forum.dlang.org/post/n25qkc$2il8$1@digitalmars.com

[JackStouffer]

I think this should be closed, due to the fact that the inout issue has been pretty much dropped.

[9il]

If we are getting rid of inout, that decision hasn't been publicly announced, and we should at least wait until the path forward for those who depend on it is sorted.

+1

[andralex]

This simplifies code regardless of inout, so I guess it should be pulled. I'm recusing myself from reviewing it so I'll take out the label.

[PetarKirov]

@andralex The min, max changes are good, but I'm against the change of signature. inout works well for what it is, so there's no need to replace it with an inferior solution. ref is the thing that needs fixing - being not part of the type it leads to ugly hacks and various limitations. If you disagree, please write a std.range.zip and std.range.enumerate alternatives that both 1) return ranges and 2) provide ref access usable in foreach and 3) without using string mixins. BTW, I think that even using string mixins wont help there.
Excuse me for the harsh tone, but I can't understand why you're trying to remove a useful feature without even a proper DIP supported by the community, whereas you're against any attempts to fixing ref on the grounds backwards compatibility (which would not be a problem in practice).
Removing inout without any alternative will put the D at disadvantage, whereas improving ref will make D more expressive and will enable designs not possible before - e.g. tuples supporting ref access and by extension the above-mentioned examples and many more.

[schveiguy]

Can we separate the removal of inout from the obvious improvements of using std.algorithm.min/max? I think that PR could be pulled immediately.

[9il]

We are spending to much efforts for this PR

[9il]

Auto-merge toggled on

[andralex]

@9il well put thanks