Re: Beta D 2.068.1-b2
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.
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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=
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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.
Re: Beta D 2.068.1-b2
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?
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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. Hmm, I'm not sure. This overloads toString. I'm assuming the minimal case is just toString? Yes. -- /Jacob Carlborg
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
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
Re: Beta D 2.068.1-b2
On Tue, Sep 1, 2015 at 8:34 AM, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 2015-08-31 08:01, Martin Nowak wrote:
>
>> First beta for the 2.068.1 point release (we skipped -b1 due to a bug).
>>
>
> Here's a piece of code that used to compile in 2.067.0 but not in 2.068.0:
>
> class UniText
> {
> abstract const char[] toString (char[] dst = null);
> abstract const wchar[] toString16 (wchar[] dst = null);
> abstract const dchar[] toString32 (dchar[] dst = null);
> }
>
> The error message is:
>
> Error: class main.UniText use of object.Object.toString() is hidden by
> UniText; use 'alias toString = Object.toString;' to introduce base class
> overload set
>
> I suspect this is intended?
>
> --
> /Jacob Carlborg
>
Yep, that is intended. You have to explicitly "import" overload sets. It
does seem to me that if there is only one function in the other overload
set the error could be disabled, however it is clearer the way it works in
2.068.
And it will get us used to having to be explicit when adding to overload
sets like in the code above.
Re: Beta D 2.068.1-b2
On 2015-08-31 08:01, Martin Nowak wrote:
First beta for the 2.068.1 point release (we skipped -b1 due to a bug).
Here's a piece of code that used to compile in 2.067.0 but not in 2.068.0:
class UniText
{
abstract const char[] toString (char[] dst = null);
abstract const wchar[] toString16 (wchar[] dst = null);
abstract const dchar[] toString32 (dchar[] dst = null);
}
The error message is:
Error: class main.UniText use of object.Object.toString() is hidden by
UniText; use 'alias toString = Object.toString;' to introduce base class
overload set
I suspect this is intended?
--
/Jacob Carlborg
Re: Beta D 2.068.1-b2
On 9/1/15 2:34 AM, Jacob Carlborg wrote:
On 2015-08-31 08:01, Martin Nowak wrote:
First beta for the 2.068.1 point release (we skipped -b1 due to a bug).
Here's a piece of code that used to compile in 2.067.0 but not in 2.068.0:
class UniText
{
abstract const char[] toString (char[] dst = null);
abstract const wchar[] toString16 (wchar[] dst = null);
abstract const dchar[] toString32 (dchar[] dst = null);
}
The error message is:
Error: class main.UniText use of object.Object.toString() is hidden by
UniText; use 'alias toString = Object.toString;' to introduce base class
overload set
I suspect this is intended?
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.
I'm assuming the minimal case is just toString?
-Steve
Beta D 2.068.1-b2
First beta for the 2.068.1 point release (we skipped -b1 due to a bug). http://downloads.dlang.org/pre-releases/2.x/2.068.1/ http://ftp.digitalmars.com/ Also available on Travis-CI as dmd-2.068.1-b2. This beta comes with plent dmd and a few druntime, phobos, and installer fixes. https://github.com/D-Programming-Language/dmd/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/druntime/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/phobos/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/installer/compare/v2.068.0...v2.068.1-b2 Please report any bugs at https://issues.dlang.org. -Martin
Re: Beta D 2.068.1-b2
On 2015-08-31 08:01, Martin Nowak wrote:
First beta for the 2.068.1 point release (we skipped -b1 due to a bug).
I started compile my projects with DMD 2.068.0 (yes, I know I'm a bit
late). I noted that this piece of code that compiles in 2.067.0 doesn't
compile in 2.068.0 (or 2.068.1-b2) :
class Foo
{
override string toString()
in { }
body
{
return "foo";
}
}
The error message I get is:
main.d(3): Error: function main.Foo.toString cannot have an in contract
when overriden function object.Object.toString does not have an in contract
The above code is a minimal testcase extracted from Tango.
The question is, is this a regression or expected? I suspect it's
expected. The check was added four years ago, although I don't
understand why it hasn't been hit before.
--
/Jacob Carlborg
Re: Beta D 2.068.1-b2
On 2015-08-31 08:01, Martin Nowak wrote: Please report any bugs at https://issues.dlang.org. https://issues.dlang.org/show_bug.cgi?id=14986 -- /Jacob Carlborg
Re: Beta D 2.068.1-b2
On Monday, 31 August 2015 at 07:08:20 UTC, Jacob Carlborg wrote:
On 2015-08-31 08:01, Martin Nowak wrote:
First beta for the 2.068.1 point release (we skipped -b1 due
to a bug).
I started compile my projects with DMD 2.068.0 (yes, I know I'm
a bit late). I noted that this piece of code that compiles in
2.067.0 doesn't compile in 2.068.0 (or 2.068.1-b2) :
class Foo
{
override string toString()
in { }
body
{
return "foo";
}
}
The error message I get is:
main.d(3): Error: function main.Foo.toString cannot have an in
contract when overriden function object.Object.toString does
not have an in contract
The above code is a minimal testcase extracted from Tango.
The question is, is this a regression or expected? I suspect
it's expected. The check was added four years ago, although I
don't understand why it hasn't been hit before.
https://issues.dlang.org/show_bug.cgi?id=14988
- Kenji
Re: Beta D 2.068.1-b2
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. I meant 'temple' without vibe.d
Re: Beta D 2.068.1-b2
On Monday, 31 August 2015 at 06:02:08 UTC, Martin Nowak wrote: First beta for the 2.068.1 point release (we skipped -b1 due to a bug). http://downloads.dlang.org/pre-releases/2.x/2.068.1/ http://ftp.digitalmars.com/ Also available on Travis-CI as dmd-2.068.1-b2. This beta comes with plent dmd and a few druntime, phobos, and installer fixes. https://github.com/D-Programming-Language/dmd/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/druntime/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/phobos/compare/v2.068.0...v2.068.1-b2 https://github.com/D-Programming-Language/installer/compare/v2.068.0...v2.068.1-b2 Please report any bugs at https://issues.dlang.org. -Martin 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.
