On Monday, 5 January 2015 at 22:04:58 UTC, Steven Schveighoffer wrote:
> Making some way to bundle attributes, or be able to negate currently one-way attributes would go a long way IMO.

Yeah. I wish it would be possilbe to do something like:

alias @smooth = @save pure nothrow @nogc;

and then use this instead.

Dominikus Dittes Scherkl:

> Yeah. I wish it would be possilbe to do something like:
>
> alias @smooth = @save pure nothrow @nogc;
>
> and then use this instead.

You most probably want something more principled instead, as the algebra of effects of Koka language (http://rise4fun.com/Koka/tutorial/guide ) or something even better.

Bye,
bearophile

On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:
> Dominikus Dittes Scherkl:
>
>> Yeah. I wish it would be possilbe to do something like:
>>
>> alias @smooth = @save pure nothrow @nogc;
>>
>> and then use this instead.
>
> You most probably want something more principled instead, as the algebra of effects of Koka language (http://rise4fun.com/Koka/tutorial/guide ) or something even better.
>
> Bye,
> bearophile

Sounds interesting, but would be hard to cover other attributes (or effects) like @save and @nogc within this system.
And I think using alias for creating combined attributes by hand would be easy to implement, not breaking any existing code and handy enough for most common combinations.
And by the way, this would also allow to define ore remove the @ as one wiches:
alias nogc = @nogc;
or vice versa:
alias @pure = pure;

On Tuesday, 6 January 2015 at 09:11:10 UTC, bearophile wrote:
> You most probably want something more principled instead, as the algebra of effects of Koka language (http://rise4fun.com/Koka/tutorial/guide ) or something even better.

Thanks for sharing the link. I had not heard of Koka before.

On 1/6/15 1:48 AM, Walter Bright wrote:
> 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.

OK, Mr. Literal :) Sorry, I should have said "impossible without totally screwing up the code"

-Steve

On Tuesday, 6 January 2015 at 06:48:34 UTC, Walter Bright wrote:
>> 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.

Is it bikeshedding time?? If so, I was thinking '@~' to be the universal canceller... @~pure, @~final. I'm only half kidding.

On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer wrote:
> 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

I cannot remember what the exact issue is now as it was awhile ago, but it had to do with a creating inout/const/immutable Nullables. When doing something such as `Nullable!TestStruct ts; writeln(ts)`, the check inside Nullable.get is triggered instead of calling toString, because toString is not marked as inout/const/immutable. The only solution seems to have a separate version of toString for inout, const, and immutable. It seems that pretty much defeats the point of having inout in the first place.

On 1/8/15 4:04 PM, Meta wrote:
> On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer wrote:
>> 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
>
> I cannot remember what the exact issue is now as it was awhile ago, but
> it had to do with a creating inout/const/immutable Nullables. When doing
> something such as `Nullable!TestStruct ts; writeln(ts)`, the check
> inside Nullable.get is triggered instead of calling toString, because
> toString is not marked as inout/const/immutable. The only solution seems
> to have a separate version of toString for inout, const, and immutable.
> It seems that pretty much defeats the point of having inout in the first
> place.

That sounds like the delegate issue. If you are not dealing with delegates, then it works well.

Working with inout delegates gets tricky, because it's impossible to refer to inout the type constructor as a parameter to a function without the compiler thinking this is a new invocation of inout.

Timon Gehr had ideas on how to fix it, but I don't think anything ever came of it.

-Steve