Consider:

https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152

There is no explanation to it in the source code, and the line blames to https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).

Commenting it out yields a number of unittest compilation errors, neither informative about the root of the problem and indicative as to how the parameter solves it.

There are two issues here:

1. Once a problem/solution pair of this degree of subtlety crops up, we need to convince ourselves that that's sensible. If we deem it not so, we look into improving the language to make the problem disappear.

2. There needs to be documentation for people working on the standard library so they don't need to waste time on their own discovery process.

We want Phobos to be beautiful, a prime example of good D code. Admittedly, it also needs to be very general and efficient, which sometimes gets in the way. But we cannot afford an accumulation of mad tricks to obscure the large design.


Andrei

On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu wrote:
> Consider:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
>
> There is no explanation to it in the source code, and the line blames to https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).

I heard that sometimes git blame can track moving data between files, but this is not such a case.

You can continue the blame by blaming the old path starting from the commit preceding that one:

git blame c828a08b64de067eeb2ddcad8fed22b2cd92e438^ -- range.d

> Commenting it out yields a number of unittest compilation errors, neither informative about the root of the problem and indicative as to how the parameter solves it.

I'm not sure what errors you saw but the first one is that this fails:

    static assert( isInputRange!(inout(int)[]));

git blame on this line points to:

https://issues.dlang.org/show_bug.cgi?id=7824

On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d wrote:
> Consider:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi tives.d#L152
>
> There is no explanation to it in the source code, and the line blames to https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).
>
> Commenting it out yields a number of unittest compilation errors, neither informative about the root of the problem and indicative as to how the parameter solves it.
>
> There are two issues here:
>
> 1. Once a problem/solution pair of this degree of subtlety crops up, we need to convince ourselves that that's sensible. If we deem it not so, we look into improving the language to make the problem disappear.
>
> 2. There needs to be documentation for people working on the standard library so they don't need to waste time on their own discovery process.
>
> We want Phobos to be beautiful, a prime example of good D code. Admittedly, it also needs to be very general and efficient, which sometimes gets in the way. But we cannot afford an accumulation of mad tricks to obscure the large design.

IIRC, the problem has to do with ranges of inout elements working correctly, which gets really funky, because inout is a temporary thing and not a full-on type constructor/qualifier. I believe that Kenji is the one that implemented the fix, and I think that he explained it in the newsgroup at some point. Certainly, there have been a few times that it's come up in D.Learn when folks ask what the heck it is, so there should be a few posts floating around with an explanation. This is the only useful post that I could find in a quick search though:

http://forum.dlang.org/post/mh68p8$2p56$1@digitalmars.com

inout attempts to solve a very real problem, but it does seem to be surprisingly hard to understand and use prooperly even though it's theoretically simple. And this bit with ranges is a quirk that I think very few people understand and remember. I usually forget exactly what it does when it comes up and have to try and dig through the newsgroup archives for a previous discussion on it.

- Jonathan M Davis

On 04/15/2016 12:23 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d
> wrote:
>> Consider:
>>
>> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi
>> tives.d#L152
>>
>> There is no explanation to it in the source code, and the line blames to
>> https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).
>>
>> Commenting it out yields a number of unittest compilation errors,
>> neither informative about the root of the problem and indicative as to
>> how the parameter solves it.
>>
>> There are two issues here:
>>
>> 1. Once a problem/solution pair of this degree of subtlety crops up, we
>> need to convince ourselves that that's sensible. If we deem it not so,
>> we look into improving the language to make the problem disappear.
>>
>> 2. There needs to be documentation for people working on the standard
>> library so they don't need to waste time on their own discovery process.
>>
>> We want Phobos to be beautiful, a prime example of good D code.
>> Admittedly, it also needs to be very general and efficient, which
>> sometimes gets in the way. But we cannot afford an accumulation of mad
>> tricks to obscure the large design.
>
> IIRC, the problem has to do with ranges of inout elements working correctly,
> which gets really funky, because inout is a temporary thing and not a
> full-on type constructor/qualifier. I believe that Kenji is the one that
> implemented the fix, and I think that he explained it in the newsgroup at
> some point. Certainly, there have been a few times that it's come up in
> D.Learn when folks ask what the heck it is, so there should be a few posts
> floating around with an explanation. This is the only useful post that I
> could find in a quick search though:
>
> http://forum.dlang.org/post/mh68p8$2p56$1@digitalmars.com
>
> inout attempts to solve a very real problem, but it does seem to be
> surprisingly hard to understand and use prooperly even though it's
> theoretically simple. And this bit with ranges is a quirk that I think very
> few people understand and remember. I usually forget exactly what it does
> when it comes up and have to try and dig through the newsgroup archives for
> a previous discussion on it.
>
> - Jonathan M Davis

I think we should deprecate inout. For real. It costs way too much for what it does. For all I can tell most of D's proponents don't know how it works. -- Andrei

On Friday, 15 April 2016 at 05:38:56 UTC, Andrei Alexandrescu wrote:
> I think we should deprecate inout. For real. It costs way too much for what it does. For all I can tell most of D's proponents don't know how it works. -- Andrei

What would replace it in the case of classes, where you can't have templated virtual methods? Perhaps a mechanism to declare a templated virtual function, and a list of instantiations which will go into the vtable?

If we are to kill inout and replace it with something else, then it should support cases where inout failed, such as inout on the parameter of a delegate passed to the function (see: inout opApply).

On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu wrote:
> Consider:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
>
> There is no explanation to it in the source code, and the line blames to https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).
>
> Commenting it out yields a number of unittest compilation errors, neither informative about the root of the problem and indicative as to how the parameter solves it.
>
> There are two issues here:
>
> 1. Once a problem/solution pair of this degree of subtlety crops up, we need to convince ourselves that that's sensible. If we deem it not so, we look into improving the language to make the problem disappear.
>
> 2. There needs to be documentation for people working on the standard library so they don't need to waste time on their own discovery process.
>
> We want Phobos to be beautiful, a prime example of good D code. Admittedly, it also needs to be very general and efficient, which sometimes gets in the way. But we cannot afford an accumulation of mad tricks to obscure the large design.
>
>
> Andrei

`(int inout = 0)` is not the only problem with that template -- and it's bothered me for years.

`is(typeof( () { ... } ) )` as a whole looks like a "trick" to me.  It's not going to be immediately obvious to someone who reads the D spec, and then that code, what that template does.

I think that behavioral type checks are common enough in D that it should have it's own first-class syntax.

-Shammah

On 4/14/2016 8:10 PM, Andrei Alexandrescu wrote:
> Commenting it out yields a number of unittest compilation errors, neither
> informative about the root of the problem and indicative as to how the parameter
> solves it.

https://issues.dlang.org/show_bug.cgi?id=15926

I think it has something to do with making the function, in this case a lambda, inout, so that it can accept inout types. Then the typeof bit is a weird way to writing something like __traits(compiles, ...) , because functions which have no type result in void, and that fails the typeof check.

If we do end up replacing inout with something else, I would like something which solves the problem of declaring functions returning ranges of either mutable, const, or immutable. I've struggled with that before: https://github.com/w0rp/dstruct/blob/master/source/dstruct/graph.d#L628

On Friday, 15 April 2016 at 07:33:42 UTC, w0rp wrote:
> I think it has something to do with making the function, in this case a lambda, inout, so that it can accept inout types. Then the typeof bit is a weird way to writing something like __traits(compiles, ...) , because functions which have no type result in void, and that fails the typeof check.
>
> If we do end up replacing inout with something else, I would like something which solves the problem of declaring functions returning ranges of either mutable, const, or immutable. I've struggled with that before: https://github.com/w0rp/dstruct/blob/master/source/dstruct/graph.d#L628

To clarify my example. My problem was that I had a container which was immutable, and I wanted a range over the immutable elements, where the range itself is of course mutable. Getting that to work was a tad tricky. You can't take an inout() container and return an inout() range, because then an immutable container will produce an immutable range, which isn't useful. I don't think you can return a mutable range containing inout() elements either.

On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
> IIRC, the problem has to do with ranges of inout elements working correctly, which gets really funky, because inout is a temporary thing and not a full-on type constructor/qualifier. I believe that Kenji is the one that implemented the fix, and I think that he explained it in the newsgroup at some point. Certainly, there have been a few times that it's come up in D.Learn when folks ask what the heck it is, so there should be a few posts floating around with an explanation. This is the only useful post that I could find in a quick search though:
>

Whatever the problem is, none of this seems like a good solution.