On 4/15/16 4:34 PM, Andrei Alexandrescu wrote:
> On 04/15/2016 04:16 PM, Steven Schveighoffer wrote:
>> If you find such advertisement useless, you of course do not need inout
>> or const.
>
> Let's not exaggerate by putting them together. -- Andrei

This is not an exaggeration. inout and const have pretty much the same benefits and drawbacks, with only a couple of major differences. The main feature of const/inout is advertisement of non-mutation. Otherwise, we could do with just mutable and immutable + templates.

-Steve

Am Fri, 15 Apr 2016 14:48:26 -0400
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
> > On 4/15/16 1:24 PM, Andrei Alexandrescu wrote:
> >> auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
> >> if (is(typeof(r1.ptr < r2.ptr) == bool))
> >> {
> >>      import std.algorithm : min, max;
> >>      auto b = max(r1.ptr, r2.ptr);
> >>      auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
> >>      return b < e ? b[0 .. e - b] : null;
> >> }
> >>
> >> Who wore it better?
> >
> > inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
> > {
> >      import std.algorithm: min, max;
> >      auto b = max(r1.ptr, r2.ptr);
> >      auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
> >      return b < e ? b[0 .. e - b] : null;
> > }
> 
> Is that better or worse than the one without inout? -- Andrei

I tend to write functions in the latter style, to avoid
unneeded template instantiations. In this case it also
documents the intent better. Both arrays are of the same type
T and we wont modify the contents.

Even if the compiler can remove binary identical instances after the fact, the compile time and memory use increases. It also has implications on debugging. After duplicate removal, you cannot map a function address to a unique symbol name any more.

Just my 2¢.

-- 
Marco

On 04/15/2016 04:45 PM, Steven Schveighoffer wrote:
> On 4/15/16 4:34 PM, Andrei Alexandrescu wrote:
>> On 04/15/2016 04:16 PM, Steven Schveighoffer wrote:
>>> If you find such advertisement useless, you of course do not need inout
>>> or const.
>>
>> Let's not exaggerate by putting them together. -- Andrei
>
> This is not an exaggeration.

Jesus. C++ has const without inout. We used to have const without inout - and we probably should again. -- Andrei

On 04/15/2016 04:47 PM, Marco Leise wrote:
> Am Fri, 15 Apr 2016 14:48:26 -0400
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
>>> On 4/15/16 1:24 PM, Andrei Alexandrescu wrote:
>>>> auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
>>>> if (is(typeof(r1.ptr < r2.ptr) == bool))
>>>> {
>>>>       import std.algorithm : min, max;
>>>>       auto b = max(r1.ptr, r2.ptr);
>>>>       auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
>>>>       return b < e ? b[0 .. e - b] : null;
>>>> }
>>>>
>>>> Who wore it better?
>>>
>>> inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
>>> {
>>>       import std.algorithm: min, max;
>>>       auto b = max(r1.ptr, r2.ptr);
>>>       auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
>>>       return b < e ? b[0 .. e - b] : null;
>>> }
>>
>> Is that better or worse than the one without inout? -- Andrei
>
> I tend to write functions in the latter style, to avoid
> unneeded template instantiations. In this case it also
> documents the intent better. Both arrays are of the same type
> T and we wont modify the contents.

Thanks, this is a good point that needs keeping in mind.

> Even if the compiler can remove binary identical instances
> after the fact, the compile time and memory use increases.
> It also has implications on debugging. After duplicate
> removal, you cannot map a function address to a unique symbol
> name any more.

This is perhaps weaker.


Andrei

On 4/15/16 5:01 PM, Andrei Alexandrescu wrote:
> On 04/15/2016 04:45 PM, Steven Schveighoffer wrote:
>> On 4/15/16 4:34 PM, Andrei Alexandrescu wrote:
>>> On 04/15/2016 04:16 PM, Steven Schveighoffer wrote:
>>>> If you find such advertisement useless, you of course do not need inout
>>>> or const.
>>>
>>> Let's not exaggerate by putting them together. -- Andrei
>>
>> This is not an exaggeration.
>
> Jesus. C++ has const without inout. We used to have const without inout
> - and we probably should again. -- Andrei

"C++ has it" is a terrible argument.

If you care about advertisement, you can't use templates to advertise whether something is const or not. Your solution is "let's use templates instead". That works, but obviously, compiler will let you molest whatever data you want. Then advertisement is done with documentation and trust.

C++ simply doesn't have that capability to advertise const for the things inout can, but also const isn't as restrictive in C++, so you can put const on things that aren't really const. IIRC Walter says C++ const is useless for guarantees (and I agree with that).

Tell me what the benefits of const are. Pretty much all the arguments you are saying for getting rid of inout (that don't involve corner cases we can fix) can be used to say we should get rid of const too. Why stop getting rid of complexity at inout?

-Steve

On 04/15/2016 05:27 PM, Steven Schveighoffer wrote:
> On 4/15/16 5:01 PM, Andrei Alexandrescu wrote:
>> On 04/15/2016 04:45 PM, Steven Schveighoffer wrote:
>>> On 4/15/16 4:34 PM, Andrei Alexandrescu wrote:
>>>> On 04/15/2016 04:16 PM, Steven Schveighoffer wrote:
>>>>> If you find such advertisement useless, you of course do not need
>>>>> inout
>>>>> or const.
>>>>
>>>> Let's not exaggerate by putting them together. -- Andrei
>>>
>>> This is not an exaggeration.
>>
>> Jesus. C++ has const without inout. We used to have const without inout
>> - and we probably should again. -- Andrei
>
> "C++ has it" is a terrible argument.

You're losing track of the thread of the argument. It's not an argument, it's the factual correct refutation of your wrong claim.

> If you care about advertisement, you can't use templates to advertise
> whether something is const or not. Your solution is "let's use templates
> instead". That works, but obviously, compiler will let you molest
> whatever data you want. Then advertisement is done with documentation
> and trust.
>
> C++ simply doesn't have that capability to advertise const for the
> things inout can, but also const isn't as restrictive in C++, so you can
> put const on things that aren't really const. IIRC Walter says C++ const
> is useless for guarantees (and I agree with that).
>
> Tell me what the benefits of const are. Pretty much all the arguments
> you are saying for getting rid of inout (that don't involve corner cases
> we can fix) can be used to say we should get rid of const too. Why stop
> getting rid of complexity at inout?

The simple answer is const pays enough, inout doesn't.

Anyhow this meandering is the kiss of death - this exchange is becoming a time-wasting back and forth, exactly the kind I promised myself to not get involved in. I'll keep your good points in mind when deciding whether we should rid D of inout.


Thanks,

Andrei

On Friday, April 15, 2016 13:46:24 Andrei Alexandrescu via Digitalmars-d wrote:
> On 04/15/2016 01:31 PM, Namespace wrote:
> > Since it is a template: Why these attributes: @trusted pure nothrow ?
>
> @trusted is not inferrable, the others are type-independent and nice for the documentation. -- Andrei

Yes. I definitely think that it should be standard policy in Phobos (if not D code in general) to only use attribute inference when it's actually required. Without attribute inference, attributes and templates really wouldn't work together (which is why we have it), but the cost is that you don't know what the actual attributes are without compiling the code. So, while some folks may not like the extra typing, I think that it's clearly better for everyone who has to look at or maintain a function and/or its documentation to know what its attributes are by looking just at it, even if it's a little bit of extra work for the person who writes the function initially.

I honestly wish that we hadn't added attribute inference to auto return functions, since I think that it's just enabling a bad practice.

- Jonathan M Davis

On Friday, 15 April 2016 at 17:24:19 UTC, Andrei Alexandrescu wrote:
> inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted

BTW, why is overlap undocumented - is ctfe support a good enough reason?
https://github.com/dlang/phobos/blob/v2.071.0/std/array.d#L715

I've thought about implementing something similar, good to know it's there. I wonder if there are places in Phobos that could use this.

Also, its unittest needs to get undocumented too, it's appearing in the previous symbol's documentation instead.

On Friday, 15 April 2016 at 21:01:44 UTC, Andrei Alexandrescu wrote:
> Jesus. C++ has const without inout. We used to have const without inout - and we probably should again. -- Andrei

What about immutability? E.g. Java gets away with immutable in a library and it just werks.

On Friday, 15 April 2016 at 18:46:01 UTC, Steven Schveighoffer wrote:
> inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2)

Might be nice if inout applied to template parameter types:

T[] overlap(inout T)(T[] r1, T[] r2);

If it wasn't for the virtual function issue, I wonder if inout would still be needed on runtime arguments given the above feature?

Using traits like CopyConstness might be enough.