digitalmars.D.announce - Beta D 2.068.1-b2
- Martin Nowak (12/12) Aug 30 2015 First beta for the 2.068.1 point release (we skipped -b1 due to a bug).
- Jacob Carlborg (4/5) Aug 31 2015 https://issues.dlang.org/show_bug.cgi?id=14986
- Jacob Carlborg (22/23) Aug 31 2015 I started compile my projects with DMD 2.068.0 (yes, I know I'm a bit
- Kenji Hara (3/26) Aug 31 2015 https://issues.dlang.org/show_bug.cgi?id=14988
- BBasile (11/21) Aug 31 2015 It looks like there is a regression in variant.d:
- BBasile (2/14) Aug 31 2015 I meant 'temple' without vibe.d
- BBasile (6/18) Sep 05 2015 waiting feedback:
- Dylan Knutson (6/12) Sep 05 2015 Bugzilla filed for reduced test case. It looks like a DMD
- Jacob Carlborg (15/16) Aug 31 2015 Here's a piece of code that used to compile in 2.067.0 but not in 2.068....
- Rory McGuire via Digitalmars-d-announce (8/25) Aug 31 2015 Yep, that is intended. You have to explicitly "import" overload sets. It
- Steven Schveighoffer (6/20) Sep 01 2015 I'm not 100% sure, but that does seem like a bug.
- Jacob Carlborg (5/9) Sep 01 2015 Yes.
- Jacob Carlborg (5/6) Sep 01 2015 I see now that there's a deprecation message when compiling with
- Steven Schveighoffer (4/8) Sep 04 2015 Really? I don't see any deprecation message for your exact code posted
- Steven Schveighoffer (3/13) Sep 04 2015 I take it back, the message occurs if you make the function concrete.
- Jacob Carlborg (6/9) Sep 01 2015 Perhaps we need an explicit way to tell the compile we want to hide a
- Meta (3/12) Sep 02 2015 Isn't that what `override` is for?
- Jacob Carlborg (7/8) Sep 02 2015 No. Think of it like you want to have a new method with the same name as...
- Martin Nowak (22/23) Sep 04 2015 The problem is that you're hiding a method that is still
- Steven Schveighoffer (4/25) Sep 04 2015 Why did this compile/pass tests then? I wasn't aware of this restriction...
- Steven Schveighoffer (22/24) Sep 04 2015 OK, I dug into it further.
- Jacob Carlborg (6/25) Sep 04 2015 I haven't turned off deprecations. This is in Tango and it seems no one
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
Aug 30 2015
Jacob Carlborg <doob me.com> 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
Aug 31 2015
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
Aug 31 2015
On Monday, 31 August 2015 at 07:08:20 UTC, Jacob Carlborg wrote:On 2015-08-31 08:01, Martin Nowak wrote:https://issues.dlang.org/show_bug.cgi?id=14988 - KenjiFirst 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.
Aug 31 2015
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. -MartinIt 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.
Aug 31 2015
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:I meant 'temple' without vibe.d[...]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.
Aug 31 2015
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: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.[...]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.
Sep 05 2015
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
Sep 05 2015
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
Aug 31 2015
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: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.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
Aug 31 2015
On 9/1/15 2:34 AM, Jacob Carlborg wrote:On 2015-08-31 08:01, Martin Nowak 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. I'm assuming the minimal case is just toString? -SteveFirst 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?
Sep 01 2015
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
Sep 01 2015
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
Sep 01 2015
On 9/1/15 3:13 PM, Jacob Carlborg wrote:On 2015-09-01 15:40, Steven Schveighoffer wrote:Really? I don't see any deprecation message for your exact code posted when compiled on 2.067. -SteveI'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.
Sep 04 2015
On 9/4/15 8:20 AM, Steven Schveighoffer wrote:On 9/1/15 3:13 PM, Jacob Carlborg wrote:I take it back, the message occurs if you make the function concrete. -SteveOn 2015-09-01 15:40, Steven Schveighoffer wrote:Really? I don't see any deprecation message for your exact code posted when compiled on 2.067.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.
Sep 04 2015
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 correctly. -- /Jacob Carlborg
Sep 01 2015
On Tuesday, 1 September 2015 at 19:15:48 UTC, Jacob Carlborg wrote:On 2015-09-01 15:40, Steven Schveighoffer wrote:Isn't that what `override` is for?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 this if I recall correctly.
Sep 02 2015
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, [1] https://msdn.microsoft.com/en-us/library/435f1dw2.aspx -- /Jacob Carlborg
Sep 02 2015
On Wednesday, 2 September 2015 at 18:20:49 UTC, Jacob Carlborg wrote:On 2015-09-02 17:51, Meta wrote:'super') --- 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=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 documentation [1]. [1] https://msdn.microsoft.com/en-us/library/435f1dw2.aspx
Sep 04 2015
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:correct link: https://msdn.microsoft.com/en-us/library/ms173153.aspx[...]apart from a compiler warning (https://msdn.microsoft.com/en-us/library/ms173153.aspx=
Sep 04 2015
On Friday, 4 September 2015 at 11:44:44 UTC, BBasile wrote:
'super')
---
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.
Sep 04 2015
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/4e799b75ebcb6d00ccefbcfd763a1f5d158357a /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.
Sep 04 2015
On 9/4/15 8:04 AM, Martin Nowak wrote:On Tuesday, 1 September 2015 at 06:33:30 UTC, Jacob Carlborg wrote:Why did this compile/pass tests then? I wasn't aware of this restriction. https://github.com/D-Programming-Language/phobos/pull/3572 -SteveI 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.
Sep 04 2015
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/3572OK, 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
Sep 04 2015
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
Sep 04 2015