www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta D 2.068.1-b2

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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
next sibling parent Jacob Carlborg <doob me.com> writes:
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
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent "Kenji Hara" <k.hara.pg gmail.com> writes:
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
Aug 31 2015
prev sibling next sibling parent reply "BBasile" <bb.temp gmx.com> writes:
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.
Aug 31 2015
next sibling parent "BBasile" <bb.temp gmx.com> writes:
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
Aug 31 2015
prev sibling parent reply "BBasile" <bb.temp gmx.com> writes:
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.
Sep 05 2015
parent "Dylan Knutson" <tcdknutson gmail.com> writes:
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
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
next sibling parent Rory McGuire via Digitalmars-d-announce writes:
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.
Aug 31 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 01 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
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
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 04 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 04 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 01 2015
parent reply "Meta" <jared771 gmail.com> writes:
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?
Sep 02 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 02 2015
parent reply "BBasile" <bb.temp gmx.com> writes:
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=
Sep 04 2015
next sibling parent "BBasile" <bb.temp gmx.com> writes:
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
Sep 04 2015
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:
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.
Sep 04 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
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
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 04 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 04 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
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