On 2015-09-01 15:40, Steven Schveighoffer wrote:

> I'm not 100% sure, but that does seem like a bug.

I see now that there's a deprecation message when compiling with 2.067.0. So it looks like it's intended.

-- 
/Jacob Carlborg

On 2015-09-01 15:40, Steven Schveighoffer wrote:

> I'm not 100% sure, but that does seem like a bug.
>
> You should be able to completely mask toString from a base class if you
> don't specify override IMO.

Perhaps we need an explicit way to tell the compile we want to hide a method in the base class. C# uses the "new" keyword for this if I recall correctly.

-- 
/Jacob Carlborg

On Tuesday, 1 September 2015 at 19:15:48 UTC, Jacob Carlborg wrote:
> On 2015-09-01 15:40, Steven Schveighoffer wrote:
>
>> I'm not 100% sure, but that does seem like a bug.
>>
>> You should be able to completely mask toString from a base class if you
>> don't specify override IMO.
>
> Perhaps we need an explicit way to tell the compile we want to hide a method in the base class. C# uses the "new" keyword for this if I recall correctly.

Isn't that what `override` is for?

On 2015-09-02 17:51, Meta wrote:

> Isn't that what `override` is for?

No. Think of it like you want to have a new method with the same name as a method in the base class. It's for hiding a method in the base class, not overriding it. See the C# documentation [1].

[1] https://msdn.microsoft.com/en-us/library/435f1dw2.aspx

-- 
/Jacob Carlborg

On Wednesday, 2 September 2015 at 18:20:49 UTC, Jacob Carlborg wrote:
> On 2015-09-02 17:51, Meta wrote:
>
>> Isn't that what `override` is for?
>
> No. Think of it like you want to have a new method with the same name as a method in the base class. It's for hiding a method in the base class, not overriding it. See the C# documentation [1].
>
> [1] https://msdn.microsoft.com/en-us/library/435f1dw2.aspx

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=

On Friday, 4 September 2015 at 11:44:44 UTC, BBasile wrote:
> On Wednesday, 2 September 2015 at 18:20:49 UTC, Jacob Carlborg wrote:
>> [...]
>
> apart from a compiler warning (https://msdn.microsoft.com/en-us/library/ms173153.aspx=

correct link:

https://msdn.microsoft.com/en-us/library/ms173153.aspx

On Tuesday, 1 September 2015 at 06:33:30 UTC, Jacob Carlborg wrote:
> I suspect this is intended?

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 ;).

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.

On 9/4/15 8:04 AM, Martin Nowak wrote:
> On Tuesday, 1 September 2015 at 06:33:30 UTC, Jacob Carlborg wrote:
>> I suspect this is intended?
>
> 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 ;).
>
> 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.

Why did this compile/pass tests then? I wasn't aware of this restriction.

https://github.com/D-Programming-Language/phobos/pull/3572

-Steve

On 9/1/15 3:13 PM, Jacob Carlborg wrote:
> On 2015-09-01 15:40, Steven Schveighoffer wrote:
>
>> I'm not 100% sure, but that does seem like a bug.
>
> I see now that there's a deprecation message when compiling with
> 2.067.0. So it looks like it's intended.
>

Really? I don't see any deprecation message for your exact code posted when compiled on 2.067.

-Steve

On 9/4/15 8:20 AM, Steven Schveighoffer wrote:
> On 9/1/15 3:13 PM, Jacob Carlborg wrote:
>> On 2015-09-01 15:40, Steven Schveighoffer wrote:
>>
>>> I'm not 100% sure, but that does seem like a bug.
>>
>> I see now that there's a deprecation message when compiling with
>> 2.067.0. So it looks like it's intended.
>>
>
> Really? I don't see any deprecation message for your exact code posted
> when compiled on 2.067.

I take it back, the message occurs if you make the function concrete.

-Steve