On 1/5/15 8:06 AM, deadalnix wrote:
> On Monday, 29 December 2014 at 20:26:27 UTC, Steven Schveighoffer wrote:
>> On 12/29/14 2:50 PM, Walter Bright wrote:
>>> On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
>>>> On 12/28/14 4:33 PM, Walter Bright wrote:
>>>>> inout is not transitive, so a ref on the container doesn't apply to a
>>>>> ref on the contents if there's another level of indirection in there.
>>>> I'm not sure what you mean by this, but inout as a type modifier is
>>>> definitely
>>>> transitive.
>>>
>>> As a type modifier, yes, it is transitive. As transferring lifetime to
>>> the return value, it is not.
>>>
>>
>> I strongly suggest not to use inout to mean this. This idea would be a
>> disaster.
>
> On the other hand, inout IS a disaster, so why not ?

I strongly disagree :) inout enables so many things that just aren't possible otherwise.

Most recent example: https://github.com/D-Programming-Language/druntime/pull/1079

inout only gets confusing when you start using inout delegates.

-Steve

On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer wrote:
> On 1/5/15 8:06 AM, deadalnix wrote:
>> On Monday, 29 December 2014 at 20:26:27 UTC, Steven Schveighoffer wrote:
>>> On 12/29/14 2:50 PM, Walter Bright wrote:
>>>> On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
>>>>> On 12/28/14 4:33 PM, Walter Bright wrote:
>>>>>> inout is not transitive, so a ref on the container doesn't apply to a
>>>>>> ref on the contents if there's another level of indirection in there.
>>>>> I'm not sure what you mean by this, but inout as a type modifier is
>>>>> definitely
>>>>> transitive.
>>>>
>>>> As a type modifier, yes, it is transitive. As transferring lifetime to
>>>> the return value, it is not.
>>>>
>>>
>>> I strongly suggest not to use inout to mean this. This idea would be a
>>> disaster.
>>
>> On the other hand, inout IS a disaster, so why not ?
>
> I strongly disagree :) inout enables so many things that just aren't possible otherwise.
>
> Most recent example: https://github.com/D-Programming-Language/druntime/pull/1079
>
> inout only gets confusing when you start using inout delegates.
>
> -Steve

IMO, inout (and const/immutable to a degree) is a failure for use with class/struct methods. This became clear to me when trying to use it for the toString implementation of Nullable.

On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer wrote:
> I strongly disagree :) inout enables so many things that just aren't possible otherwise.
>
> Most recent example: https://github.com/D-Programming-Language/druntime/pull/1079
>
> inout only gets confusing when you start using inout delegates.
>
> -Steve

You are arguing that inout is useful. That simply makes it a useful disaster :)

On 1/5/15 11:51 AM, deadalnix wrote:
> On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer wrote:
>> I strongly disagree :) inout enables so many things that just aren't
>> possible otherwise.
>>
>> Most recent example:
>> https://github.com/D-Programming-Language/druntime/pull/1079
>>
>> inout only gets confusing when you start using inout delegates.
>>
>
> You are arguing that inout is useful. That simply makes it a useful
> disaster :)

I guess you and me have different ideas of what a disaster is :)

-Steve

On 1/5/15 10:05 AM, Meta wrote:

> IMO, inout (and const/immutable to a degree) is a failure for use with
> class/struct methods. This became clear to me when trying to use it for
> the toString implementation of Nullable.

You'd have to be more specific for me to understand your point. inout was specifically designed for one-implementation accessors for members of classes/structs.

-Steve

On 12/30/2014 4:14 AM, Steven Schveighoffer wrote:
> But I agree. The problem is, most times, you WANT to ensure your code is @safe
> pure nothrow (and now @nogc), even for template functions. That's a lot of
> baggage to put on each signature. I just helped someone recently who wanted to
> put @nogc on all the std.datetime code, and every signature had these 4
> attributes except a few. I tried to have him put a big @safe: pure: nothrow:
> @nogc: at the top, but the occasional exceptions made this impossible.

The way to do it is one of:

1. reorganize the code so the non-attributed ones come first

2. write the attributes as:

   @safe pure nothrow @nogc {
      ... functions ...
   }

   ... non attributed functions ...

   @safe pure nothrow @nogc {
      ... more functions ...
   }

On Monday, 5 January 2015 at 19:18:34 UTC, Steven Schveighoffer wrote:
> On 1/5/15 11:51 AM, deadalnix wrote:
>> On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer wrote:
>>> I strongly disagree :) inout enables so many things that just aren't
>>> possible otherwise.
>>>
>>> Most recent example:
>>> https://github.com/D-Programming-Language/druntime/pull/1079
>>>
>>> inout only gets confusing when you start using inout delegates.
>>>
>>
>> You are arguing that inout is useful. That simply makes it a useful
>> disaster :)
>
> I guess you and me have different ideas of what a disaster is :)
>
> -Steve

Nop. Great usefulness makes it almost impossible to get rid of in its current form.

On 1/5/15 4:10 PM, Walter Bright wrote:
> On 12/30/2014 4:14 AM, Steven Schveighoffer wrote:
>> But I agree. The problem is, most times, you WANT to ensure your code
>> is @safe
>> pure nothrow (and now @nogc), even for template functions. That's a
>> lot of
>> baggage to put on each signature. I just helped someone recently who
>> wanted to
>> put @nogc on all the std.datetime code, and every signature had these 4
>> attributes except a few. I tried to have him put a big @safe: pure:
>> nothrow:
>> @nogc: at the top, but the occasional exceptions made this impossible.
>
> The way to do it is one of:
>
> 1. reorganize the code so the non-attributed ones come first
>
> 2. write the attributes as:
>
>     @safe pure nothrow @nogc {
>        ... functions ...
>     }
>
>     ... non attributed functions ...
>
>     @safe pure nothrow @nogc {
>        ... more functions ...
>     }

To give you an example of why that sucks, imagine that your accessor for member_x is nothrow, but your setter is not. This means you either "make an exception", or you just split up obvious file-mates into separate corners. Source control gets confused if one of those attributes changes. Nobody is happy.

Grouping by attributes is probably one of the worst ways to have readable/maintainable code.

One of the most important reasons why unittests are so successful is that you can just plop the code that tests a function right next to it. So easy to find the code, so easy to maintain when you change the target of the test. Making some way to bundle attributes, or be able to negate currently one-way attributes would go a long way IMO.

-Steve

On Sunday, 4 January 2015 at 01:12:14 UTC, Manu via Digitalmars-d wrote:
> It's like this: ref is a massive problem when it finds it's way into meta.
> ref is relatively rare today... so the problem is occasional.
> scope on the other hand will be epic compared to ref. If we infer
> scope (which we'll probably need to), chances are, the vast majority
> of functions will involve scope.
> We can't have the trouble with ref (read: trouble with 'storage
> class') applied to the majority of functions.

Hey Manu, I think it would still be a good idea to provide code examples of your points right in the forums. I was able to look at the file from luaD and see how the problems were occurring, but it would hasten my understanding just to see several 'reduced test cases' of that example and others, if possible.

On 1/5/2015 2:04 PM, Steven Schveighoffer wrote:
> To give you an example of why that sucks, imagine that your accessor for
> member_x is nothrow, but your setter is not. This means you either "make an
> exception", or you just split up obvious file-mates into separate corners.
> Source control gets confused if one of those attributes changes. Nobody is happy.
>
> Grouping by attributes is probably one of the worst ways to have
> readable/maintainable code.
>
> One of the most important reasons why unittests are so successful is that you
> can just plop the code that tests a function right next to it. So easy to find
> the code, so easy to maintain when you change the target of the test. Making
> some way to bundle attributes, or be able to negate currently one-way attributes
> would go a long way IMO.


I know and agree. I was just responding to the 'impossible' characterization.