On Fri, 14 Mar 2014 11:17:08 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 3/14/14, 4:37 AM, Daniel Murphy wrote:
>> "Walter Bright"  wrote in message news:lfu74a$8cr$1@digitalmars.com...
>>
>>> > No, it doesn't, because it is not usable if C introduces any virtual
>>> > methods.
>>>
>>> That's what the !final storage class is for.
>>
>> My mistake, I forgot you'd said you were in favor of this.  Being able
>> to 'escape' final certainly gets us most of the way there.
>>
>> !final is really rather hideous though.
>
> A few possibilities discussed around here:
>
> !final
> ~final
> final(false)
> @disable final
>
> I've had an epiphany literally a few seconds ago that "final(false)" has the advantage of being generalizable to "final(bool)" taking any CTFE-able Boolean.

Yes yes yes!

Consider also final!false (i.e. parameterize final)

-Steve

On Friday, 14 March 2014 at 15:17:08 UTC, Andrei Alexandrescu wrote:
> On 3/14/14, 4:37 AM, Daniel Murphy wrote:
>> "Walter Bright"  wrote in message news:lfu74a$8cr$1@digitalmars.com...
>>
>>> > No, it doesn't, because it is not usable if C introduces any virtual
>>> > methods.
>>>
>>> That's what the !final storage class is for.
>>
>> My mistake, I forgot you'd said you were in favor of this.  Being able
>> to 'escape' final certainly gets us most of the way there.
>>
>> !final is really rather hideous though.
>
> A few possibilities discussed around here:
>
> !final
> ~final
> final(false)
> @disable final
>
> I've had an epiphany literally a few seconds ago that "final(false)" has the advantage of being generalizable to "final(bool)" taking any CTFE-able Boolean.
>
> On occasion I needed a computed qualifier (I think there's code in Phobos like that) and the only way I could do it was through ugly code duplication or odd mixin-generated code. Allowing computed qualifiers/attributes would be a very elegant and general approach, and plays beautifully into the strength of D and our current investment in Boolean compile-time predicates.
>
>
> Andrei

Yeah. My idea is popular.

On Friday, 14 March 2014 at 15:17:08 UTC, Andrei Alexandrescu wrote:
> Allowing computed qualifiers/attributes would be a very elegant and general approach, and plays beautifully into the strength of D and our current investment in Boolean compile-time predicates.
>

Bonus points if inout can be replaced that way :)

14-Mar-2014 19:17, Andrei Alexandrescu пишет:
> On 3/14/14, 4:37 AM, Daniel Murphy wrote:
>> "Walter Bright"  wrote in message news:lfu74a$8cr$1@digitalmars.com...
>>
>>> > No, it doesn't, because it is not usable if C introduces any virtual
>>> > methods.
>>>
>>> That's what the !final storage class is for.
>>
>> My mistake, I forgot you'd said you were in favor of this.  Being able
>> to 'escape' final certainly gets us most of the way there.
>>
>> !final is really rather hideous though.
>
> A few possibilities discussed around here:
>
> !final
> ~final
> final(false)
> @disable final
>
> I've had an epiphany literally a few seconds ago that "final(false)" has
> the advantage of being generalizable to "final(bool)" taking any
> CTFE-able Boolean.
>
> On occasion I needed a computed qualifier (I think there's code in
> Phobos like that) and the only way I could do it was through ugly code
> duplication or odd mixin-generated code. Allowing computed
> qualifiers/attributes would be a very elegant and general approach, and
> plays beautifully into the strength of D and our current investment in
> Boolean compile-time predicates.

+1 for qualifier(bool_expression)



-- 
Dmitry Olshansky

On 2014-03-14 15:17:08 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> A few possibilities discussed around here:
> 
> !final
> ~final
> final(false)
> @disable final
> 
> I've had an epiphany literally a few seconds ago that "final(false)" has the advantage of being generalizable to "final(bool)" taking any CTFE-able Boolean.
> 
> On occasion I needed a computed qualifier (I think there's code in Phobos like that) and the only way I could do it was through ugly code duplication or odd mixin-generated code. Allowing computed qualifiers/attributes would be a very elegant and general approach, and plays beautifully into the strength of D and our current investment in Boolean compile-time predicates.

final(bool) is my preferred solution too.

It certainly is more verbose than 'virtual', but it offers more possibilities. Also, the pattern is already somewhat established with align(int).

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

"Andrei Alexandrescu"  wrote in message news:lfv6hk$12su$1@digitalmars.com...

> A few possibilities discussed around here:
>
> !final
> ~final
> final(false)

None of those are as nice as 'virtual'.  It's not like it's a common variable name.

> @disable final

Nope, already valid.

> I've had an epiphany literally a few seconds ago that "final(false)" has the advantage of being generalizable to "final(bool)" taking any CTFE-able Boolean.
>
> On occasion I needed a computed qualifier (I think there's code in Phobos like that) and the only way I could do it was through ugly code duplication or odd mixin-generated code. Allowing computed qualifiers/attributes would be a very elegant and general approach, and plays beautifully into the strength of D and our current investment in Boolean compile-time predicates.

This is a much bigger change than adding a new storage class, both from the language and implementation perspectives.  How often do you really need this much power, now that we have attribute inference? 

On 3/14/14, 7:18 AM, Steven Schveighoffer wrote:
> There are some times where AorB is the best description, and the
> machinery to factor out is just unnecessarily verbose.

Innocently entering the fray :o).

1. I don't quite understand the sheer strength of opinion of Walter's in this particular matter. It's as if you chat with a friend and suddenly you figure he has a disproportionately strong opinion on some small matter. The argument is always the same invoking some so-bad-it's-painful-to-recount past experience. I do take the point but can't stop thinking I also have past experience to draw from that's not as traumatizing. Something that I did notice is very bad (and version awesomely avoids it) is the possibility to re#define macros in C such that the meaning of code depends on what has been sequentially read/included. But Boolean operators don't seem to have had a huge impact. So I'm always left a bit confused.

2. I have comparable difficulty understanding why the "opposition" feels also so strongly about it. There are various good means to approach versioning challenges without compromising. (Rikki's idea was new to me!)


Andrei

On 3/14/14, 8:30 AM, Namespace wrote:
> On Friday, 14 March 2014 at 15:17:08 UTC, Andrei Alexandrescu wrote:
>> On 3/14/14, 4:37 AM, Daniel Murphy wrote:
>>> "Walter Bright"  wrote in message news:lfu74a$8cr$1@digitalmars.com...
>>>
>>>> > No, it doesn't, because it is not usable if C introduces > any
>>>> virtual
>>>> > methods.
>>>>
>>>> That's what the !final storage class is for.
>>>
>>> My mistake, I forgot you'd said you were in favor of this. Being able
>>> to 'escape' final certainly gets us most of the way there.
>>>
>>> !final is really rather hideous though.
>>
>> A few possibilities discussed around here:
>>
>> !final
>> ~final
>> final(false)
>> @disable final
>>
>> I've had an epiphany literally a few seconds ago that "final(false)"
>> has the advantage of being generalizable to "final(bool)" taking any
>> CTFE-able Boolean.
>>
>> On occasion I needed a computed qualifier (I think there's code in
>> Phobos like that) and the only way I could do it was through ugly code
>> duplication or odd mixin-generated code. Allowing computed
>> qualifiers/attributes would be a very elegant and general approach,
>> and plays beautifully into the strength of D and our current
>> investment in Boolean compile-time predicates.
>>
>>
>> Andrei
>
> Yeah. My idea is popular.

Apologies for not having seen it!

Andrei

On 3/14/14, 8:43 AM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:lfv6hk$12su$1@digitalmars.com...
>> On occasion I needed a computed qualifier (I think there's code in
>> Phobos like that) and the only way I could do it was through ugly code
>> duplication or odd mixin-generated code. Allowing computed
>> qualifiers/attributes would be a very elegant and general approach,
>> and plays beautifully into the strength of D and our current
>> investment in Boolean compile-time predicates.
>
> This is a much bigger change than adding a new storage class, both from
> the language and implementation perspectives.

We can just start with final(false). The point is the syntax offers a path to progress.

> How often do you really
> need this much power, now that we have attribute inference?

I'm not sure. It's a good question.


Andrei

Am Fri, 14 Mar 2014 23:34:46 +0900
schrieb Mike Parker <aldacron@gmail.com>:

> When I do need something like this, I just define some manifest constants in a config module, import that everywhere, and use static if. But that feels very much like the workaround it is. I would much prefer to have boolean versions. The bottom line is that I'm doing exactly what Walter apparently doesn't want me to do anyway, just with the added annoyance of importing an extra module to get it done.

I use manifest constants instead of version identifiers as well. If a version identifier affects the public API/ABI of a library, then the library and all code using the library always have to be compiled with the same version switches(inlining and templates make this an even bigger problem). This is not only inconvenient, it's also easy to think of examples where the problem will only show up as crashes at runtime. The only reason why that's not an issue in phobos/druntime is that we only use compiler defined versions there, but user defined versions are almost unusable.