On 04/15/2016 05:07 AM, Timon Gehr wrote:
> The fundamental problem is that inout is disallows certain kinds of
> composition. It's a flawed language primitive.

I agree. The more I try things with it the more awfully complex and useless it is. inout must go. -- Andrei

On 04/15/2016 03:42 AM, deadalnix wrote:
> 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.

I agree. -- Andrei

On 04/15/2016 02:49 AM, Walter Bright wrote:
> 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

Nice, thanks. I think I can put a finger on what bothers me the most: adding that "inout int = 0" to make code work cannot be an acceptable solution to any problem. So the fact that the problem exists is the actual problem. It's basic sense and sensibility in engineering. -- Andrei

On 04/15/2016 02:40 AM, Shammah Chancellor wrote:
> I think that behavioral type checks are common enough in D that it
> should have it's own first-class syntax.

No. -- Andrei

On Friday, 15 April 2016 at 12:54:11 UTC, ixid wrote:
>
> Why didn't we go with all functions being able to infer const, pure etc rather than just templates?

Non-templated function may not have their source code available. For consistency, non-template function have no inference.

On 04/15/2016 02:15 AM, Vladimir Panteleev wrote:
> 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?

You write several one-liners that forward to an internal template implementation.

> 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).

I think we should kill it, period. No replacement is really needed, for the most part most problems with inout are complications caused by the very presence of inout.

C++ has no parameterization of qualifiers and lived with it like a guy lives with a bald spot on a butt cheek. There's not even a proposal I can remember to fix that. Those duplications are the least of C++'s, or any langauge's, problems.

inout must go.


Andrei

On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
> Consider:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152

It works around a limitation of inout that isn't necessary (even though I thought it was being helpful when I suggested it). That is, functions without inout parameters cannot declare local inout variables. But this isn't really necessary, and should be fixed. I will discuss this in my talk in a few weeks.

Note, the =0 part isn't necessary right now, since it's not called. It's just used to test if the function can compile.

In short, my opinion on inout is that it has some unnecessary limitations, which can be removed, and inout will work as mostly expected. These requirements to work around the limitations will go away.

I expect after reading this thread that the Q&A will be.. interesting.

-Steve

2016-04-15 22:41 GMT+09:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>:

> On 04/15/2016 06:50 AM, Kenji Hara via Digitalmars-d wrote:
>
>>
>>
>> You should recall the history of inout. http://wiki.dlang.org/DIP2
>>
>> At first, It has designed to temporarily squash mutable/const/immutable qualifiers on function argument inside function body. Therefore when inout qualifier appears in function return type, but doesn't on parameter types, we defined it an error.
>>
>> However, I concluded that we can remove the restriction. When an inout object arises from thin air, no one holds the qualifier of its real instance. It means, the returned inout object can be converted to arbitrary qualifiers without type system breaking.
>>
>> Two years ago I opened an enhancement issue: https://issues.dlang.org/show_bug.cgi?id=13006
>>
>> And posted a pull request. https://github.com/D-Programming-Language/dmd/pull/3740
>>
>
> I do recall the history. The enhancement is sensible in a frame of mind "we need to keep inout" but I'm looking at top level and thinking, crap we can put up with a little duplication if we get rid of inout. It's just a prime example of apparently simple idea gone bonkers.
>
> In all of my recent code I've avoided inout and didn't miss it one bit. There's no need for it - I replace it with one-liners that forward to template functions, which in turn deduce qualifiers and all is great.


Didn't you use array.dup until now? It's a good example to handle
qualifiers with inout.
It's not sensible at all, inout is already well-defined and has much power
in D's type system.
Removing it is just a foolish idea.

If you worry the future of Phobos written in D, first you would need to
think about @safe.
It's yet not well defined/implemented by compiler, and many Phobos code are
marked as @trusted.
Does it has lower priority than complain to a small hack for the *current*
inout limitation?

I just cannot agree your argument.

Kenji Hara

On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote:
>
> Didn't you use array.dup until now? It's a good example to handle
> qualifiers with inout.

Would it be difficult to make it work without inout?

> It's not sensible at all, inout is already well-defined and has much
> power in D's type system.
> Removing it is just a foolish idea.

What are a few examples of the power of inout?

What things does inout afford us, that would be otherwise not achievable?

> If you worry the future of Phobos written in D, first you would need to
> think about @safe.
> It's yet not well defined/implemented by compiler, and many Phobos code
> are marked as @trusted.
> Does it has lower priority than complain to a small hack for the
> *current* inout limitation?

The thing about @safe is it does enable things that otherwise would not be possible. Overall I agree there are plenty of things that deserve a revisit, but just putting in competition things against one another is unlikely to shed light on their technical merit.

> I just cannot agree your argument.

I understand and would like to be better informed. So could you please substantiate your argument by replying to the questions above?

To restate my arguments:

1. The motivation of inout is clear and simple - have it as a placeholder for any other qualifier so as to avoid the method duplication observed in C++. However, it has over time grown into a feature of which complexity way transcends its small usefulness.

2. Attempting to make inout useful have created their own problems, solving which in turn have increased its complexity. This cycle of accretions has led over time to a vortex of oddity in the middle of the type system.

3. For all problems that inout is purported to solve, I know of idioms that are definitely simpler and overall almost as good if not better. So a hard question is whether the existence is justified.

There are 306 uses of inout in Phobos. A good thing to do would be an investigation of their usefulness.


Andrei

On Friday, 15 April 2016 at 17:11:39 UTC, Andrei Alexandrescu wrote:
>
> 3. For all problems that inout is purported to solve, I know of idioms that are definitely simpler and overall almost as good if not better. So a hard question is whether the existence is justified.

If it's something to be avoided except in particular cases, then I suggest that is made clear in the documentation. I had not realized that the main reason that inout was added was because of not being able to use templates as virtual functions in classes.