March 18, 2012
Le 18/03/2012 16:26, Andrei Alexandrescu a écrit :
> On 3/18/12 8:39 AM, deadalnix wrote:
>> It just show the need of keyword to express the opposite of final,
>> virtual. The same problem occur with const immutable, you cannot go back
>> to the mutable world when you use « const: » for example.
>
> Yah, ~const etc. have been suggested a couple of times. Helps casts too.
>
> Andrei

This seems definitively an issue to me. ~const/~final, or mutable/virtual would be a huge benefice to the « : » syntax. And youa re right, it is also a big plus for casting. I would argue for teh last one, especially for the const case, because mutable oppose to both const and immutable, so it isn't the opposite of const.

The case is very similar to public/private/protected, and each have it's own keyword, and it doesn't seems armful.

Note that the same issue exist for shared (but that one doesn't work anyway).
March 18, 2012
>> This is so much theoretical that I think this should be removed from the D docs. And to be put back when one DMD compiler is able to do this. Otherwise it's just false advertising :-)
>
> Is this even possible without LTO/WPO? Extending a class defined in a library you link in (and for which codegen already happened) is certainly possible…
>
> David

This is not even possible with LTO because new classes
could be loaded at runtime.
Could somebody please fix this.
March 18, 2012
Le 18/03/2012 17:02, Martin Nowak a écrit :
>>> This is so much theoretical that I think this should be removed from
>>> the D docs. And to be put back when one DMD compiler is able to do
>>> this. Otherwise it's just false advertising :-)
>>
>> Is this even possible without LTO/WPO? Extending a class defined in a
>> library you link in (and for which codegen already happened) is
>> certainly possible…
>>
>> David
>
> This is not even possible with LTO because new classes
> could be loaded at runtime.
> Could somebody please fix this.

That is limited to export classes. In this case, final/virtual should be managed very precisely anyway if performance matter.
March 18, 2012
On 03/18/12 02:23, Manu wrote:
> The virtual model broken. I've complained about it lots, and people always say "stfu, use 'final:' at the top of your class".
> 
> That sounds tolerable in theory, except there's no 'virtual' keyword to keep the virtual-ness of those 1-2 virtual functions I have... so it's no good (unless I rearrange my class, breaking the logical grouping of stuff in it).
> So I try that, and when I do, it complains: "Error: variable demu.memmap.MemMap.machine final cannot be applied to variable", allegedly a D1 remnant.
> So what do I do? Another workaround? Tag everything as final individually?
> 
> My minimum recommendation: D needs an explicit 'virtual' keyword, and to fix that D1 bug, so putting final: at the top of your class works, and everything from there works as it should.

See subject.

Example;

class Foo : Bar final {
}

as alternative syntax for

class Foo : Bar { final {
} }

Advantages: internally consistent, no need for completely new syntax, "final class" can be deprecated (it never worked well anyway).

Alternate aspects of this syntax change:

void foo(ObjectThing ot, int a, int b) with (ot) {
}

void bar() synchronized {
}
March 18, 2012
On 03/18/2012 05:25 PM, FeepingCreature wrote:
>
> Advantages: internally consistent, no need for completely new syntax, "final class" can be deprecated (it never worked well anyway).
>

final class means that the class cannot be inherited from.
March 18, 2012
On Sunday, 18 March 2012 at 16:02:04 UTC, Martin Nowak wrote:
>> Is this even possible without LTO/WPO? Extending a class defined in a library you link in (and for which codegen already happened) is certainly possible…
>>
>> David
>
> This is not even possible with LTO because new classes
> could be loaded at runtime.

Sure, you can't just devirtualize everything you come across even with LTO, but it greatly increases the portion of calls where you can deduce the actual type of an instance.

David

March 18, 2012
Le 18/03/2012 17:49, Timon Gehr a écrit :
> On 03/18/2012 05:25 PM, FeepingCreature wrote:
>>
>> Advantages: internally consistent, no need for completely new syntax,
>> "final class" can be deprecated (it never worked well anyway).
>>
>
> final class means that the class cannot be inherited from.

What is the point to inherit is no virtual method exists ?
March 18, 2012
On Sun, 18 Mar 2012 18:07:10 +0100, deadalnix <deadalnix@gmail.com> wrote:

> Le 18/03/2012 17:49, Timon Gehr a écrit :
>> On 03/18/2012 05:25 PM, FeepingCreature wrote:
>>>
>>> Advantages: internally consistent, no need for completely new syntax,
>>> "final class" can be deprecated (it never worked well anyway).
>>>
>>
>> final class means that the class cannot be inherited from.
>
> What is the point to inherit is no virtual method exists ?

Access to protected members.
March 18, 2012
David Nadlinger wrote:
> Which is wrong as long as you don't do link-time optimization, and DMD probably won't in the foreseeable future.

Are GDC and LDC limited by DMD in this regard? I know LDC has a LTO flag.

If GDC/LDC supports LTO and/or DMD will in the eventual future, then I think defaulting to final is best. If you're saying that even with LTO you wouldn't be able to do automatic de-virtualization ever, then I think Manu might be right in saying the model is backwards. I don't know enough about LTO to comment either way though.

FeepingCreature wrote:
> class Foo : Bar final {
> }
>
> as alternative syntax for
>
> class Foo : Bar { final {
> } }
>
> Advantages: internally consistent, no need for completely new syntax, "final class" can be deprecated (it never worked well anyway).
>
> Alternate aspects of this syntax change:
>
> void foo(ObjectThing ot, int a, int b) with (ot) {
> }
>
> void bar() synchronized {
> }

+1 This syntax makes a lot of sense.

March 18, 2012
On Sunday, 18 March 2012 at 17:24:15 UTC, F i L wrote:
> […] I know LDC has a  LTO flag.

Unfortunately it doesn't (-O4/-O5 are defunct), but working on seamless LTO integration (and better optimization pass scheduling in general) would be low-hanging fruit for anybody wanting to join LDC development.

David