On 6/3/2013 11:49 PM, deadalnix wrote:
> We can do it in a D specific way (using our own metadata and providing an
> optimization pas for LLVM) but most likely we won't even need to as the same
> feature is planned to be added to clang and we can most likely simply reuse
> clang's metadata.

There is another way.

D can be made aware that it is building an executable (after all, that is why it invokes the linker). If you shove all the source code into the compiler in one command, for an executable, functions that are not overridden can be made final.

On 6/3/2013 10:58 PM, Andrei Alexandrescu wrote:
> Unless fresh arguments, facts, or perspectives come about, I am personally not
> convinced, based on this thread so far, that we should operate a language change.

One possibility is to introduce virtual as a storage class that overrides final. Hence, one could write a class like:

class C {
  final:
    void foo();
    void baz();
    virtual int abc();
    void def();
}

This would not break any existing code, and Manu would just need to get into the habit of having "final:" as the first line in his classes.

On 6/4/2013 2:25 AM, Walter Bright wrote:
>
> One possibility is to introduce virtual as a storage class that
> overrides final. Hence, one could write a class like:
>
> class C {
>    final:
>      void foo();
>      void baz();
>      virtual int abc();
>      void def();
> }
>
> This would not break any existing code, and Manu would just need to get
> into the habit of having "final:" as the first line in his classes.

The problem isn't going to be in your own code, it will be in using everyone elses.

On Tuesday, 4 June 2013 at 05:41:16 UTC, Rob T wrote:
> Structs would IMO be far more useful if they had inheritance. Inheritence can be fully removed from the rest of polymorphism, so there's no reason why structs which are not polymorphic cannot inherit.

If no polymorphism is needed, there is no reason to use inheritance instead of template mixins.

On Tuesday, 4 June 2013 at 07:12:34 UTC, Walter Bright wrote:
> On 6/3/2013 11:49 PM, deadalnix wrote:
>> We can do it in a D specific way (using our own metadata and providing an
>> optimization pas for LLVM) but most likely we won't even need to as the same
>> feature is planned to be added to clang and we can most likely simply reuse
>> clang's metadata.
>
> There is another way.
>
> D can be made aware that it is building an executable (after all, that is why it invokes the linker). If you shove all the source code into the compiler in one command, for an executable, functions that are not overridden can be made final.

It has been discussed several times - no, they can't unless export is strict. One can create a shared library that inherits a class from main executable and get reference to it in main executable via reference to a known class (base).

On Tuesday, June 04, 2013 00:25:39 Walter Bright wrote:
> On 6/3/2013 10:58 PM, Andrei Alexandrescu wrote:
> > Unless fresh arguments, facts, or perspectives come about, I am personally not convinced, based on this thread so far, that we should operate a language change.
> One possibility is to introduce virtual as a storage class that overrides final. Hence, one could write a class like:
> 
> class C {
>    final:
>      void foo();
>      void baz();
>      virtual int abc();
>      void def();
> }
> 
> This would not break any existing code, and Manu would just need to get into the habit of having "final:" as the first line in his classes.

That would be good regardless of whether virtual or non-virtual is the default. In general, the function attributes other than access level specifiers and @safety attributes suffer from not being able to be undone once you use them with a colon or {}.

- Jonathan M Davis

On Tuesday, 4 June 2013 at 07:12:34 UTC, Walter Bright wrote:
> On 6/3/2013 11:49 PM, deadalnix wrote:
>> We can do it in a D specific way (using our own metadata and providing an
>> optimization pas for LLVM) but most likely we won't even need to as the same
>> feature is planned to be added to clang and we can most likely simply reuse
>> clang's metadata.
>
> There is another way.
>
> D can be made aware that it is building an executable (after all, that is why it invokes the linker). If you shove all the source code into the compiler in one command, for an executable, functions that are not overridden can be made final.

I think is interesting, because all open source software can be build from sources and can also be done on some commercial products in certain conditions. And compiling the world with D is realistic, due to small compilation time.

I also don't understand why compilers don't generate executable directly and use a linker, as they already know the binary format and do optimization. I case of DMD which take all source file in a raw, I don't see any issues. Do DMD do best inlining optimizations than the linker when it get all sources as parameter?

On Tuesday, 4 June 2013 at 07:12:34 UTC, Walter Bright wrote:
> There is another way.
>
> D can be made aware that it is building an executable (after all, that is why it invokes the linker). If you shove all the source code into the compiler in one command, for an executable, functions that are not overridden can be made final.

To do so, the compiler must know which function can be overriden in shared object (to not finalize them) and which can't.

The whole thing can also be made a link time optimization, so separate compilation model isn't broken.

It require strong (stronger that what we have now) enforcement of export.

On 6/4/2013 12:32 AM, Sean Cavanaugh wrote:
> The problem isn't going to be in your own code, it will be in using everyone elses.

If you're forced to use someone else's code and are not allowed to change it in any way, then you're always going to have problems with badly written APIs.

Even Manu mentioned that he's got problems with C++ libraries because of this, and C++ has non-virtual by default.

On 6/4/2013 12:37 AM, Dicebot wrote:
> It has been discussed several times - no, they can't unless export is strict.
> One can create a shared library that inherits a class from main executable and
> get reference to it in main executable via reference to a known class (base).

Right, I had forgotten about that.