On 9/4/15 8:14 AM, Steven Schveighoffer wrote:

> Why did this compile/pass tests then? I wasn't aware of this restriction.
>
> https://github.com/D-Programming-Language/phobos/pull/3572

OK, I dug into it further.

It seems that under some level of detection of whether a function that could be called on the base is really called on the derived, then the derived function is not allowed to mask the base function.

HOWEVER, if the call would result in an error instead, then the override is totally fine, and calling the function on a base reference actually calls the masked function. This seems incorrect, when you mask a function, I would consider that to be hidden also.

So technically, the error is that the toString masking could be called in the same way the base could be called (given the default parameter).

This sure seems arbitrary to me. I remember the whole thing about function hijacking, but this hidden function "feature" doesn't make a lot of sense. In one case, you can hide it, but still access it from the base, in another, the compiler was rewriting the vtable to not allow you to access it from the base, on what seems to be an arbitrary concern. And that now is a compiler error.

I wonder how this will affect multiple alias this, since you could potentially have a type that converts to two disjoint types, but wouldn't be known to the compiler if a base and derived class accepted the disjoint types.

-Steve

On 2015-09-04 14:04, Martin Nowak wrote:

> The problem is that you're hiding a method that is still reachable
> through the vtable.
> Rather than throwing a runtime error this was changed to a compiler error.
>
> https://github.com/D-Programming-Language/dmd/pull/4606
>
> You should not turn off deprecations btw ;).

I haven't turned off deprecations. This is in Tango and it seems no one has cared to fix those.

> The simple solution in you case is to override the inherited `string
> toString()` with an implementation that forwards to your `toString()`.
>
> class UniText
> {
>      override string toString() { return toString(null).idup; }
>      abstract const char[] toString (char[]  dst = null);
>      abstract const wchar[] toString16 (wchar[] dst = null);
>      abstract const dchar[] toString32 (dchar[] dst = null);
> }
>
> Also see at
> https://github.com/D-Programming-Language/druntime/blob/4e799b75ebcb6d00ccefbcfd763a1f5d158357a1/src/object.d#L1598
> for an example of an alternative overridable toString method.
> Maybe you should use the delegate based toString as well, it's already
> supported by a some phobos formatting.

Again, this is in Tango, I just want it to compile :)

-- 
/Jacob Carlborg

On Friday, 4 September 2015 at 11:44:44 UTC, BBasile wrote:
>
> What's so different with C# 'new' that not to call 'super' in a D overriden method ? (even if C# has itself 'base' instead of 'super')
>
> C#
> ---
> public class BaseC
> {
>     public int x;
>     public void Invoke() { }
> }
> public class DerivedC : BaseC
> {
>     new public void Invoke() { }
> }
> ---
>
> D
> ---
> class BaseC
> {
>     int x;
>     void Invoke() { }
> }
> class DerivedC : BaseC
> {
>     override void Invoke() { /*super.Invoke() not called*/ }
> }
> ---
>
> apart from a compiler warning (https://msdn.microsoft.com/en-us/library/ms173153.aspx=

It is just a warning, because it's ultimately there to warn you of something you may not have noticed.
For example:

abstract class BaseA {
    abstract void foo();
}

class A : BaseA {
    override void foo() { }
    virtual void foobar() { }
}

All is well.
But then BaseA (which may be in a different library), suddenly becomes:

abstract class BaseA {
    abstract void foo();
    virtual void foobar() { dostuff(); }
}

Now you have A, which has foobar, but isn't actually related to BaseA.foobar. You probably didn't mean to override foobar, but it's still confusing for anything expecting BaseA.foobar to be related to A.foobar. You might not even know BaseA.foobar was added if it was part of a different library. Or, even worse:

class B : A {
    override void foobar() {
        dootherstuff();
    }
}

It definitely gets a bit odd, and new is there just to prevent confusion / clarify intentions, as well as let you know when a new method is added with the same name. The whole situation is messy, like what happens when A.foobar is removed and you suddenly start overriding BaseA.foobar instead. Or what if you were intending to override BaseA.foobar, but now you're suddenly overriding A.foobar once A adds the method? I'd actually prefer to specifically have to write 'override void A.foobar()' if A.foobar is marked as 'new' for this reason and make it an error to not include new or override when dealing with the same name. D could probably benefit from this approach as well, for the same reasons.

On Monday, 31 August 2015 at 13:15:57 UTC, BBasile wrote:
> On Monday, 31 August 2015 at 06:02:08 UTC, Martin Nowak wrote:
>> [...]
>
> It looks like there is a regression in variant.d:
>
> I compile template without vibed and get:
>
> ---
> C:\Dev\dmd2\windows\bin\..\..\src\phobos\std\variant.d: Error: function std.variant.VariantN!20u.VariantN.__xopEquals errors compiling the function
> ---
>
> It looks very strange because
> - the line number is even not displayed.
> - relative path is quite unusuall in an error message.

waiting feedback:

https://github.com/dymk/temple/issues/31

this error message is so strange. Maybe the author is not very reachable now so you might also want to try to compile because you know better.

On Saturday, 5 September 2015 at 11:30:20 UTC, BBasile wrote:
> On Monday, 31 August 2015 at 13:15:57 UTC, BBasile wrote:
> waiting feedback:
>
> https://github.com/dymk/temple/issues/31
>
> this error message is so strange. Maybe the author is not very reachable now so you might also want to try to compile because you know better.

Bugzilla filed for reduced test case. It looks like a DMD regression (the reduced test case for TempleContext only compiles just fine in 2.068.0). I've included a reduced standalone temple_context.d and variant.d

https://issues.dlang.org/show_bug.cgi?id=15017