www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.070 and 2.055 release

reply Walter Bright <newshound2 digitalmars.com> writes:
By far, the most number of bug fixes ever!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.070.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.055.zip
Sep 07 2011
next sibling parent reply Caligo <iteronvexor gmail.com> writes:
SWEET!

On Thu, Sep 8, 2011 at 12:21 AM, Walter Bright
<newshound2 digitalmars.com>wrote:

 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/**1.0/changelog.html<http://www.digitalmars.com/d/1.0/changelog.html>
 http://ftp.digitalmars.com/**dmd.1.070.zip<http://ftp.digitalmars.com/dmd.1.070.zip>

 http://www.digitalmars.com/d/**2.0/changelog.html<http://www.digitalmars.com/d/2.0/changelog.html>
 http://ftp.digitalmars.com/**dmd.2.055.zip<http://ftp.digitalmars.com/dmd.2.055.zip>
Sep 07 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/7/2011 10:26 PM, Caligo wrote:
 SWEET!
And dman is here now, too! http://www.digitalmars.com/ctg/dman.html
Sep 07 2011
prev sibling next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434 is in the changelog, but 
has not been fixed.

"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j49jd4$22mu$1 digitalmars.com...
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip 
Sep 07 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 By far, the most number of bug fixes ever!
It's a nice release, thank you. I think a better index comes from dividing the number of bugs by the number of days between two adjacent releases. I have found a little trouble with std.range.indexed, I have asked in D.learn. I have added a small enhancement request for Phobos, regarding std.range.chunks: http://d.puremagic.com/issues/show_bug.cgi?id=6621 Days ago the "Warn about switch case fallthrough" from 2.054 has found a bug in one oldish D2 program of mine (I did forget to add a break, and my unittests didn't catch this very narrow corner case). Thanks. Bye, bearophile
Sep 08 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-08 07:21, Walter Bright wrote:
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
Yet another release with a lot of bugs fixed, thanks. -- /Jacob Carlborg
Sep 08 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/8/11 3:17 AM, Jacob Carlborg wrote:
 On 2011-09-08 07:21, Walter Bright wrote:
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
Yet another release with a lot of bugs fixed, thanks.
The community has surpassed its own record at number of bugs fixed for the second time in a row. Andrei
Sep 08 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-08 10:37, Andrei Alexandrescu wrote:
 On 9/8/11 3:17 AM, Jacob Carlborg wrote:
 On 2011-09-08 07:21, Walter Bright wrote:
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
Yet another release with a lot of bugs fixed, thanks.
The community has surpassed its own record at number of bugs fixed for the second time in a row. Andrei
That's great, I hope we can keep up the good work. -- /Jacob Carlborg
Sep 08 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Is there any way to drown those deprecation notices? I get a wall of
notices every time I compile..
Sep 08 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It's a shame I haven't noticed this earlier, std.path.extension()
returns the extension with the dot, getExt returns it without the dot.
This is breaking a lot of my code now. :/

I sure hope one day we'll be able to update our compiler without
breaking our code. Other than that this looks like a great release.
Good work everyone!
Sep 08 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ok cool, my DWin project successfully compiles. The WinAPI bindings
are missing extern(Windows) specifiers for its function aliases and
2.055 seems to enforce this now, so that api will have to be updated.
The only thing that's bothering me is the notices, there's just too
many of them.

For example this:

import std.stdio;
import std.path;

void main()
{
    writeln(curdir.rel2abs);
}

turns into this:
Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
deprecation in February 2012. Please use absolutePath instead.
Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
deprecation in February 2012. Please use isAbsolute instead.
Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
deprecation in February 2012. Please use driveName instead.
Notice: As of Phobos 2.055, std.path.join has been scheduled for
deprecation in February 2012. Please use buildPath instead.
Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
deprecation in February 2012. Please use absolutePath instead.
Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
deprecation in February 2012. Please use isAbsolute instead.
Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
deprecation in February 2012. Please use driveName instead.
Notice: As of Phobos 2.055, std.path.join has been scheduled for
deprecation in February 2012. Please use buildPath instead.

That is just unacceptable imho.
Sep 08 2011
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 08 Sep 2011 16:52:37 +0100, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 Ok cool, my DWin project successfully compiles. The WinAPI bindings
 are missing extern(Windows) specifiers for its function aliases and
 2.055 seems to enforce this now, so that api will have to be updated.
 The only thing that's bothering me is the notices, there's just too
 many of them.

 For example this:

 import std.stdio;
 import std.path;

 void main()
 {
     writeln(curdir.rel2abs);
 }

 turns into this:
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.

 That is just unacceptable imho.
It needs to tell you about each one only once, then it will be much more acceptable. Ideally, some way to switch deprecation notices off. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Sep 08 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 08, 2011 18:16:46 Regan Heath wrote:
 On Thu, 08 Sep 2011 16:52:37 +0100, Andrej Mitrovic
 
 <andrej.mitrovich gmail.com> wrote:
 Ok cool, my DWin project successfully compiles. The WinAPI bindings
 are missing extern(Windows) specifiers for its function aliases and
 2.055 seems to enforce this now, so that api will have to be updated.
 The only thing that's bothering me is the notices, there's just too
 many of them.
 
 For example this:
 
 import std.stdio;
 import std.path;
 
 void main()
 {
 
     writeln(curdir.rel2abs);
 
 }
 
 turns into this:
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 
 That is just unacceptable imho.
It needs to tell you about each one only once, then it will be much more acceptable. Ideally, some way to switch deprecation notices off.
It looks like it's probably being reported once per instantiation instead of just once (which makes sense I guess). Improvements to deprecated which will make it possible to have such messages without pragmas are in the works ( https://github.com/D-Programming-Language/dmd/pull/345 ), but the best way to sort that all out hasn't been decided yet. Andrei has said that he has some ideas on how to improve/fix the situation that he wants to discuss, but he hasn't said what they are yet. So, yes. The current sitatuation is annoying, but there's a good chance that it'll be improved/fix for the next release. - Jonathan M Davis
Sep 08 2011
prev sibling parent reply d coder <dlang.coder gmail.com> writes:
 Is there any way to drown those deprecation notices? I get a wall of
 notices every time I compile..
Would this DMD option help? -d allow deprecated features
Sep 08 2011
parent "Nick Sabalausky" <a a.a> writes:
"d coder" <dlang.coder gmail.com> wrote in message 
news:mailman.2759.1315502193.14074.digitalmars-d-announce puremagic.com...
 Is there any way to drown those deprecation notices? I get a wall of
 notices every time I compile..
Would this DMD option help? -d allow deprecated features
No, that's for stuff that's actually marked with "deprecated". He's talking about the "scheduled for deprecation" notices, which are just simply "pragma(msg,...);". The compiler doesn't know anything about them. ------------------------------- Not sent from an iPhone.
Sep 08 2011
prev sibling next sibling parent Damian Ziemba <nazriel driv.pl> writes:
On Wed, 07 Sep 2011 22:21:22 -0700, Walter Bright wrote:

 By far, the most number of bug fixes ever!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
Awesome! Good job Walter & community
Sep 08 2011
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Did disabled default constructor make it in here?
Sep 08 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/8/11, Adam Ruppe <destructionator gmail.com> wrote:
 Did disabled default constructor make it in here?
Yep.
Sep 08 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ok now I definitely need a dfix program. The problem is toUTFz can't
be used in UFCS like toUTF16z could, so now I have to replace all
expression.toUTF16z code to toUTFz!(const(wchar)*)(expression).
Personally I find this thing to be ugly enough to warrant a good alias
anyway.

Anyone clever enough to do this via sed?
Sep 08 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrej Mitrovic (andrej.mitrovich gmail.com)'s article
 Ok now I definitely need a dfix program. The problem is toUTFz can't
 be used in UFCS like toUTF16z could, so now I have to replace all
 expression.toUTF16z code to toUTFz!(const(wchar)*)(expression).
 Personally I find this thing to be ugly enough to warrant a good alias
 anyway.
 Anyone clever enough to do this via sed?
Uh...what's wrong with this at the top of every file: alias toUTFz!(const(wchar)*) toUTF16z;
Sep 08 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/8/11, dsimcha <dsimcha yahoo.com> wrote:
 Uh...what's wrong with this at the top of every file:

 alias toUTFz!(const(wchar)*) toUTF16z;
Maybe this is wrong: Error: template instance toUTFz!(const(wchar)*) does not match any template declaration
Sep 08 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/08/2011 06:52 PM, Andrej Mitrovic wrote:
 On 9/8/11, dsimcha<dsimcha yahoo.com>  wrote:
 Uh...what's wrong with this at the top of every file:

 alias toUTFz!(const(wchar)*) toUTF16z;
Maybe this is wrong: Error: template instance toUTFz!(const(wchar)*) does not match any template declaration
Yes, I think it D should be enhanced so that it is possible to partially apply a template using alias, that would make alias a lot more useful. For now, this will do: auto toUTF16z(S)(S str){return toUTFz!(const(wchar)*)(str);} BTW, why does toUTFz!(const(wchar)*) not work with UFCS? Is that a bug?
Sep 08 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/08/2011 08:31 PM, Timon Gehr wrote:
 On 09/08/2011 06:52 PM, Andrej Mitrovic wrote:
 On 9/8/11, dsimcha<dsimcha yahoo.com> wrote:
 Uh...what's wrong with this at the top of every file:

 alias toUTFz!(const(wchar)*) toUTF16z;
Maybe this is wrong: Error: template instance toUTFz!(const(wchar)*) does not match any template declaration
Yes, I think it D should be enhanced so that it is possible to partially apply a template using alias, that would make alias a lot more useful. For now, this will do: auto toUTF16z(S)(S str){return toUTFz!(const(wchar)*)(str);} BTW, why does toUTFz!(const(wchar)*) not work with UFCS? Is that a bug?
Ah, I get it. k, imho toUTFz should be curried. That would make both the alias and UFCS work.
Sep 08 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:j4b1lr$1s8c$1 digitalmars.com...
 On 09/08/2011 06:52 PM, Andrej Mitrovic wrote:
 On 9/8/11, dsimcha<dsimcha yahoo.com>  wrote:
 Uh...what's wrong with this at the top of every file:

 alias toUTFz!(const(wchar)*) toUTF16z;
Maybe this is wrong: Error: template instance toUTFz!(const(wchar)*) does not match any template declaration
Yes, I think it D should be enhanced so that it is possible to partially apply a template using alias, that would make alias a lot more useful.
Yea. In the meantime, you can do it manually on the template-declaration side with a nested template: template foo(A,B) { // whatever } alias foo!(x) bar; // Fail! --> template foo(A) { template foo(B) { // whatever } } alias foo!(x) bar; // Ok! Kinda annoying, but it works.
 For now, this will do:

 auto toUTF16z(S)(S str){return toUTFz!(const(wchar)*)(str);}


 BTW, why does toUTFz!(const(wchar)*) not work with UFCS? Is that a bug?
UFCS is half-broken in D2. Unfortunate, as it's one of my favorite features.
Sep 08 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/8/11, Timon Gehr <timon.gehr gmx.ch> wrote:
 For now, this will do:

 auto toUTF16z(S)(S str){return toUTFz!(const(wchar)*)(str);}
That'll do. Works with UFCS so it's perfect. It could have even stayed in std.utf like this and just forward to toUTFz internally without having to be deprecated.
Sep 08 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 08, 2011 21:40:30 Andrej Mitrovic wrote:
 On 9/8/11, Timon Gehr <timon.gehr gmx.ch> wrote:
 For now, this will do:
 
 auto toUTF16z(S)(S str){return toUTFz!(const(wchar)*)(str);}
That'll do. Works with UFCS so it's perfect. It could have even stayed in std.utf like this and just forward to toUTFz internally without having to be deprecated.
It was discussed. Andrei was in favor of just getting rid of toUTF16z (he pretty much wants to get rid of all functions that have the type in their name like that). So, we ended up scheduling toUTF16z for deprecation rather than adjusting it like that. - Jonathan M Davis
Sep 08 2011
prev sibling parent reply zeljkog <zeljkog private.com> writes:
On 08.09.2011 18:52, Andrej Mitrovic wrote:
 On 9/8/11, dsimcha<dsimcha yahoo.com>  wrote:
 Uh...what's wrong with this at the top of every file:

 alias toUTFz!(const(wchar)*) toUTF16z;
Maybe this is wrong: Error: template instance toUTFz!(const(wchar)*) does not match any template declaration
alias toUTFz!(const(wchar)*, string) toUTF16z;
Sep 08 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/8/11, zeljkog <zeljkog private.com> wrote:
 alias toUTFz!(const(wchar)*, string) toUTF16z;
That's hardcoding, my friend! Anyway I'll use that forwarding function like I've said.
Sep 08 2011
parent reply zeljkog <zeljkog private.com> writes:
On 08.09.2011 22:03, Andrej Mitrovic wrote:
 On 9/8/11, zeljkog<zeljkog private.com>  wrote:
 alias toUTFz!(const(wchar)*, string) toUTF16z;
That's hardcoding, my friend! Anyway I'll use that forwarding function like I've said.
overload: alias toUTFz!(const(wchar)*, string) toUTF16z; alias toUTFz!(const(wchar)*, wstring) toUTF16z;
Sep 08 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/8/11, zeljkog <zeljkog private.com> wrote:
 alias toUTFz!(const(wchar)*, string) toUTF16z;
 alias toUTFz!(const(wchar)*, wstring) toUTF16z;
I think one difference (if I'm right) is that using a non-templated function such as this: const(wchar)* toUTF16z(string s) { return toUTFz!(const(wchar)*)(s); } can enable me to pre-compile a module to an object file (call it unicode.obj), while using an alias the object code for toUTF16z has to be generated when the client module (main.d) is compiled.
Sep 08 2011
parent reply Adam Burton <adz21c gmail.com> writes:
Andrej Mitrovic wrote:

 On 9/8/11, zeljkog <zeljkog private.com> wrote:
 alias toUTFz!(const(wchar)*, string) toUTF16z;
 alias toUTFz!(const(wchar)*, wstring) toUTF16z;
I think one difference (if I'm right) is that using a non-templated function such as this: const(wchar)* toUTF16z(string s) { return toUTFz!(const(wchar)*)(s); } can enable me to pre-compile a module to an object file (call it unicode.obj), while using an alias the object code for toUTF16z has to be generated when the client module (main.d) is compiled.
Did some a simple test [1] and looks like the alias alone should work. I think the rule is the template code is included if it is instantiated and aliasing the template seems to be classed as instantiating it. [1] I am not great with linkers + asm so just incase I've made an obvious mistake... I created a very basic template function (tempFunction) then compiled it as a lib with and without an alias. I extracted the object files from the libs using ar and the one with the alias contained an additional object file with the mangled name of my function (_D4test1d22__T12tempFunctionTAyaZ12tempFunctionFAyaZv:).
Sep 09 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/9/11, Adam Burton <adz21c gmail.com> wrote:
 Did some a simple test [1] and looks like the alias alone should work. I
 think the rule is the template code is included if it is instantiated and
 aliasing the template seems to be classed as instantiating it.
Hmm. Interesting, because I did the same but I didn't find the symbol names when using an alias. I've used objconv to generate the asm code so maybe I passed the wrong flag or something. :)
Sep 09 2011
parent Adam Burton <adz21c gmail.com> writes:
Andrej Mitrovic wrote:

 On 9/9/11, Adam Burton <adz21c gmail.com> wrote:
 Did some a simple test [1] and looks like the alias alone 
should work. I
 think the rule is the template code is included if it is 
instantiated and
 aliasing the template seems to be classed as instantiating 
it.
 
 Hmm. Interesting, because I did the same but I didn't find 
the symbol
 names when using an alias. I've used objconv to generate the 
asm code
 so maybe I passed the wrong flag or something. :)
Well like I said it had an extra object. If I convert the modules object from inside the library then there is nothing (obj2asm), but if I list the objects in the library then there is an extra containing the template function. However if I tell dmd to create just object files (dmd -c test.d) then the function is inside the modules object file.
Sep 09 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Hacked up in two minutes to upgrade dwinproj http://codepad.org/gasNWPoK

Worked fine for all but one of ~200 modules, yay.
Sep 08 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well I'll just comment out the pragma in std.utf. Plenty of time till february.
Sep 08 2011
prev sibling parent travert phare.normalesup.org (Christophe) writes:
Andrej Mitrovic , dans le message (digitalmars.D.announce:21155), a
 écrit :
 Ok now I definitely need a dfix program. The problem is toUTFz can't
 be used in UFCS like toUTF16z could, so now I have to replace all
 expression.toUTF16z code to toUTFz!(const(wchar)*)(expression).
 Personally I find this thing to be ugly enough to warrant a good alias
 anyway.
 
 Anyone clever enough to do this via sed?
's/\([_a-zA-Z][_a-zA-Z0-9]*\) *\. *toUTF16z/toUTFz!(const(wchar)*)(\1)/g' will work with any expression that is made of one valid d identifier with no strange characters. Spaces are allowed arround the dot. I don't think this will catch anything else. However, things like templateName!expression.toUTF16z will get broken like this: templateName!toUTFz!(const(wchar)*)(expression). The compiler may not even complain... The sed expression could be modified to take care of this. Things like (expressionA ~ expressionB).toUTF16z will not be converted. I could find a patern easily for this one, but I would have to make a new one for every nested parenthesis. etc...
Sep 08 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 08, 2011 17:52:37 Andrej Mitrovic wrote:
 Ok cool, my DWin project successfully compiles. The WinAPI bindings
 are missing extern(Windows) specifiers for its function aliases and
 2.055 seems to enforce this now, so that api will have to be updated.
 The only thing that's bothering me is the notices, there's just too
 many of them.
 
 For example this:
 
 import std.stdio;
 import std.path;
 
 void main()
 {
     writeln(curdir.rel2abs);
 }
 
 turns into this:
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 
 That is just unacceptable imho.
At present, the only way to get rid of them is to fix your code so that it doesn't use the functions which are scheduled for deprecation. Improvements to the deprecated keyword have been in discussion to improve the situation. e.g. https://github.com/D-Programming-Language/dmd/pull/345 It should only be reporting once per function though, so generally it shouldn't be this bad. It's likely happening because a bunch of std.path functions call each other, and they're all templated. - Jonathan M Davis
Sep 08 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2760.1315507814.14074.digitalmars-d-announce puremagic.com...
 On Thursday, September 08, 2011 17:52:37 Andrej Mitrovic wrote:
 Ok cool, my DWin project successfully compiles. The WinAPI bindings
 are missing extern(Windows) specifiers for its function aliases and
 2.055 seems to enforce this now, so that api will have to be updated.
 The only thing that's bothering me is the notices, there's just too
 many of them.

 For example this:

 import std.stdio;
 import std.path;

 void main()
 {
     writeln(curdir.rel2abs);
 }

 turns into this:
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.

 That is just unacceptable imho.
At present, the only way to get rid of them is to fix your code so that it doesn't use the functions which are scheduled for deprecation. Improvements to the deprecated keyword have been in discussion to improve the situation. e.g. https://github.com/D-Programming-Language/dmd/pull/345 It should only be reporting once per function though, so generally it shouldn't be this bad. It's likely happening because a bunch of std.path functions call each other, and they're all templated.
Using RDMD can also inflate the number of notices, since it calls DMD twice. ------------------------------- Not sent from an iPhone.
Sep 08 2011
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Jonathan M Davis, el  8 de septiembre a las 11:49 me escribiste:
 On Thursday, September 08, 2011 17:52:37 Andrej Mitrovic wrote:
 Ok cool, my DWin project successfully compiles. The WinAPI bindings
 are missing extern(Windows) specifiers for its function aliases and
 2.055 seems to enforce this now, so that api will have to be updated.
 The only thing that's bothering me is the notices, there's just too
 many of them.
 
 For example this:
 
 import std.stdio;
 import std.path;
 
 void main()
 {
     writeln(curdir.rel2abs);
 }
 
 turns into this:
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead.
 Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
 deprecation in February 2012. Please use isAbsolute instead.
 Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
 deprecation in February 2012. Please use driveName instead.
 Notice: As of Phobos 2.055, std.path.join has been scheduled for
 deprecation in February 2012. Please use buildPath instead.
 
 That is just unacceptable imho.
At present, the only way to get rid of them is to fix your code so that it doesn't use the functions which are scheduled for deprecation. Improvements to the deprecated keyword have been in discussion to improve the situation. e.g. https://github.com/D-Programming-Language/dmd/pull/345
And this one: https://github.com/D-Programming-Language/dmd/pull/248 -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- I love las minifaldas on Esmeralda And the sexy porteños trying to pick up the Argenteenagers. How nice, the Argenteenagers Tomando sol in the primavera de Buenos Aires...
Sep 08 2011
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 08 Sep 2011 11:49:55 -0700, Jonathan M Davis wrote:

 On Thursday, September 08, 2011 17:52:37 Andrej Mitrovic wrote:
 Ok cool, my DWin project successfully compiles. The WinAPI bindings are
 missing extern(Windows) specifiers for its function aliases and 2.055
 seems to enforce this now, so that api will have to be updated. The
 only thing that's bothering me is the notices, there's just too many of
 them.
 
 For example this:
 
 import std.stdio;
 import std.path;
 
 void main()
 {
     writeln(curdir.rel2abs);
 }
 
 turns into this:
 Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
 deprecation in February 2012. Please use absolutePath instead. Notice:
 As of Phobos 2.055, std.path.isabs has been scheduled for deprecation
 in February 2012. Please use isAbsolute instead. Notice: As of Phobos
 2.055, std.path.getDrive has been scheduled for deprecation in February
 2012. Please use driveName instead. Notice: As of Phobos 2.055,
 std.path.join has been scheduled for deprecation in February 2012.
 Please use buildPath instead. Notice: As of Phobos 2.055,
 std.path.rel2abs has been scheduled for deprecation in February 2012.
 Please use absolutePath instead. Notice: As of Phobos 2.055,
 std.path.isabs has been scheduled for deprecation in February 2012.
 Please use isAbsolute instead. Notice: As of Phobos 2.055,
 std.path.getDrive has been scheduled for deprecation in February 2012.
 Please use driveName instead. Notice: As of Phobos 2.055, std.path.join
 has been scheduled for deprecation in February 2012. Please use
 buildPath instead.
 
 That is just unacceptable imho.
At present, the only way to get rid of them is to fix your code so that it doesn't use the functions which are scheduled for deprecation. Improvements to the deprecated keyword have been in discussion to improve the situation. e.g. https://github.com/D-Programming-Language/dmd/pull/345
What we could do in the meantime is to introduce the following at the top of the modules that uses the "soft deprecation" mechanism: version (NoSoftDeprecation) { } else version = SoftDeprecation; Then, we could write the deprecation messages like this: version(SoftDeprecation) pragma(msg, "Notice: As of ..."); and people could silence the compiler with -version=NoSoftDeprecation. Even better, we could define a mixin somewhere that includes the above, as well as a template containing a standardised deprecation message. That way, each module only needs to have something like this at the top: mixin (softDeprecationStuff!"std.path"); -Lars
Sep 10 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/08/2011 07:21 AM, Walter Bright wrote:
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
Thanks! I have written a program that runs about twice as fast as before when compiled with DMD 2.055. What improvement could cause this?
Sep 10 2011
parent dsimcha <dsimcha yahoo.com> writes:
On 9/10/2011 2:48 PM, Timon Gehr wrote:
 On 09/08/2011 07:21 AM, Walter Bright wrote:
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
Thanks! I have written a program that runs about twice as fast as before when compiled with DMD 2.055. What improvement could cause this?
The big ones I can think of off the top of my head are: 1. std.algorithm.copy is now specialized for arrays and is 10-80 times faster. 2. Associative arrays now use the new NO_INTERIOR GC attribute, which massively cuts down on false pointers and therefore GC times when using lots of AAs. 3. If you're using std.parallelism, the implementations of amap and parallel foreach have been completely rewritten to be more efficient, using an obvious-in-hindsight pattern that I found while working on the upcoming std.parallel_algorithm. These are at the front of my mind because they're changes that I implemented. Given the massive number of bug fixes/improvements there are probably a lot more potential reasons than those listed above.
Sep 10 2011
prev sibling parent reply Max Samukha <maxter spambox.com> writes:
On 09/08/2011 08:21 AM, Walter Bright wrote:
 By far, the most number of bug fixes ever!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.070.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.055.zip
This test case struct S { disable this(); this(int x) { } } class C { S s; this() { s = S(42); } } void main() { auto c = new C; } yields Error: default construction is disabled for type C Is it a bug?
Sep 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case

 struct S
 {
  disable this();
 this(int x)
 {
 }
 }

 class C
 {
 S s;
 this()
 {
 s = S(42);
 }
 }

 void main()
 {
 auto c = new C;
 }

 yields Error: default construction is disabled for type C

 Is it a bug?
No, it's a feature!
Sep 11 2011
next sibling parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Sun, 11 Sep 2011 10:57:12 -0700, Walter Bright wrote:

 On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case

 struct S
 {
  disable this();
 this(int x)
 {
 }
 }

 class C
 {
 S s;
 this()
 {
 s = S(42);
 }
 }

 void main()
 {
 auto c = new C;
 }

 yields Error: default construction is disabled for type C

 Is it a bug?
No, it's a feature!
class C { S s = S(0); // <-- initial value provided this() { s = S(42); } } Since C doesn't use any default constructed S, I would expect at least the above to compile. Could you please explain why the disabled default constructor of S affects C in that case (and even in Max's case). Thank you, Ali
Sep 11 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 11, 2011 18:57:03 Ali =C3=87ehreli wrote:
 On Sun, 11 Sep 2011 10:57:12 -0700, Walter Bright wrote:
 On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case
=20
 struct S
 {
  disable this();
 this(int x)
 {
 }
 }
=20
 class C
 {
 S s;
 this()
 {
 s =3D S(42);
 }
 }
=20
 void main()
 {
 auto c =3D new C;
 }
=20
 yields Error: default construction is disabled for type C
=20
 Is it a bug?
=20 No, it's a feature!
=20 class C { S s =3D S(0); // <-- initial value provided =20 this() { s =3D S(42); } } =20 Since C doesn't use any default constructed S, I would expect at leas=
t
 the above to compile.
=20
 Could you please explain why the disabled default constructor of S
 affects C in that case (and even in Max's case).
Your case should work (if it doesn't it's a bug, I believe), but Max's = won't,=20 because using S s; isn't legal when S is a struct whose default constructor has been disab= led.=20 Actually, what worries me is what happens when you try and use S.init (= I=20 haven't tried it, so I don't know what happens). S.init has effectively= been=20 made non-existent by this disable this(); but there's plenty of templa= ted=20 code out there that would try and use the init value for checking stuff= . I=20 would assume that such code would fail, but I don't know. Assuming that= such=20 code can actually work with a struct whose default initializer has been= =20 disabled, such template constraints are going to have to be written dif= ferently=20 now. - Jonathan M Davis
Sep 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2011 2:18 PM, Jonathan M Davis wrote:
 isn't legal when S is a struct whose default constructor has been disabled.
 Actually, what worries me is what happens when you try and use S.init (I
 haven't tried it, so I don't know what happens). S.init has effectively been
 made non-existent by this  disable this(); but there's plenty of templated
 code out there that would try and use the init value for checking stuff. I
 would assume that such code would fail, but I don't know. Assuming that such
 code can actually work with a struct whose default initializer has been
 disabled, such template constraints are going to have to be written differently
 now.
Using S.init is still fine. The idea is to force the use of explicit initialization.
Sep 11 2011
parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Sun, 11 Sep 2011 15:08:20 -0700, Walter Bright wrote:

 On 9/11/2011 2:18 PM, Jonathan M Davis wrote:
 isn't legal when S is a struct whose default constructor has been
 disabled. Actually, what worries me is what happens when you try and
 use S.init (I haven't tried it, so I don't know what happens). S.init
 has effectively been made non-existent by this  disable this(); but
 there's plenty of templated code out there that would try and use the
 init value for checking stuff. I would assume that such code would
 fail, but I don't know. Assuming that such code can actually work with
 a struct whose default initializer has been disabled, such template
 constraints are going to have to be written differently now.
Using S.init is still fine. The idea is to force the use of explicit initialization.
The problem is, the disabled default constructor of a *member* is making a wrapper class's constructor to be disabled as well: struct S { disable this(); this(int x) { } } class C { S s = S.init; this() { this.s = S.init; } } void main() { auto c = new C; } Error: default construction is disabled for type C C should be allowed to have a default constructor because it plays nice and does use explicit construction of S. Even if you use S.this(int) in C, it still doesn't work. I think this is at least limiting and very likely a bug. Ali
Sep 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2011 4:53 PM, Ali Çehreli wrote:
 The problem is, the disabled default constructor of a *member* is making
 a wrapper class's constructor to be disabled as well:
Right. It's infectious. This is deliberate.
 I think this is at least limiting and very
likely a bug. It's deliberate. It's likely that we can find ways to loosen things up in the future, but the idea is to screw it down tight, first, instead of allowing big holes.
Sep 11 2011
next sibling parent dsimcha <dsimcha yahoo.com> writes:
On 9/11/2011 9:07 PM, Walter Bright wrote:
 On 9/11/2011 4:53 PM, Ali Çehreli wrote:
 The problem is, the disabled default constructor of a *member* is making
 a wrapper class's constructor to be disabled as well:
Right. It's infectious. This is deliberate. > I think this is at least limiting and very likely a bug. It's deliberate. It's likely that we can find ways to loosen things up in the future, but the idea is to screw it down tight, first, instead of allowing big holes.
I've noticed that this is generally the philosophy when adding new features to D. It's sometimes frustrating initially, but I'm starting to see how it pays off in the long run, e.g. with implicitly converting arrays returned from pure functions to immutable.
Sep 11 2011
prev sibling next sibling parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Sun, 11 Sep 2011 18:07:41 -0700, Walter Bright wrote:

 On 9/11/2011 4:53 PM, Ali Çehreli wrote:
 The problem is, the disabled default constructor of a *member* is
 making a wrapper class's constructor to be disabled as well:
Right. It's infectious. This is deliberate. > I think this is at least limiting and very likely a bug. It's deliberate. It's likely that we can find ways to loosen things up in the future, but the idea is to screw it down tight, first, instead of allowing big holes.
It is common that types insist on some data when being constructed. Many of my C++ types cannot be default-constructed. I love the idea. So S insists that an int must be provided during its construction. That is great. But although one of the major tasks of C's constructor is to initialize its members, it cannot initialize an S member no matter how it tries. I can see two workarounds, none of which I believe are undesirable: 1) Insist that C defines a non-default constructor but ignores the argument with an arbitrary type: struct S { disable this(); this(int x) {} } class C { S s; this(int) { this.s = S(42); // Always 42; ignores the arg } } void main() { auto c = new C(0); // Unused 0 } 2) Use a pointer: class C { S * s; // Expensive in space this() { this.s = new S(42); // Expensive in time } } void main() { auto c = new C; } Ali
Sep 11 2011
parent Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Mon, 12 Sep 2011 04:11:42 +0000, Ali Çehreli wrote:

 I can see two workarounds, none of which I believe are undesirable:
Really? I meant they are NOT desirable. :) Ali
Sep 11 2011
prev sibling parent Max Samukha <maxter spambox.com> writes:
On 09/12/2011 04:07 AM, Walter Bright wrote:
 On 9/11/2011 4:53 PM, Ali Çehreli wrote:
 The problem is, the disabled default constructor of a *member* is making
 a wrapper class's constructor to be disabled as well:
Right. It's infectious. This is deliberate. > I think this is at least limiting and very likely a bug. It's deliberate. It's likely that we can find ways to loosen things up in the future, but the idea is to screw it down tight, first, instead of allowing big holes.
But how we can find the holes if we cannot even try things because they are screwed down tight? I think the right approach would be to loosen things up (without declaring them a complete feature, "resounding success", etc.), identify the holes and *then* seal the holes if possible or discard the whole idea as infeasible.
Sep 12 2011
prev sibling next sibling parent reply Max Samukha <maxter spambox.com> writes:
On 09/11/2011 08:57 PM, Walter Bright wrote:
 On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case

 struct S
 {
  disable this();
 this(int x)
 {
 }
 }

 class C
 {
 S s;
 this()
 {
 s = S(42);
 }
 }

 void main()
 {
 auto c = new C;
 }

 yields Error: default construction is disabled for type C

 Is it a bug?
No, it's a feature!
That's sad. The question should rather have been: what do I do to use member structs that have default constructors disabled? Initially I thought that the compiler would treat the first assignment in the constructor specially as initializer. The error message "Error: constructor test.C.this field s must be initialized in constructor" suggested that. I was wrong. So you completely disallowed runtime initialization of globals and members that have default constructors disabled? To me it looks like another feature that is a simple solution unusable in practice.
Sep 12 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/12/2011 09:38 AM, Max Samukha wrote:
 On 09/11/2011 08:57 PM, Walter Bright wrote:
 On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case

 struct S
 {
  disable this();
 this(int x)
 {
 }
 }

 class C
 {
 S s;
 this()
 {
 s = S(42);
 }
 }

 void main()
 {
 auto c = new C;
 }

 yields Error: default construction is disabled for type C

 Is it a bug?
No, it's a feature!
That's sad. The question should rather have been: what do I do to use member structs that have default constructors disabled? Initially I thought that the compiler would treat the first assignment in the constructor specially as initializer. The error message "Error: constructor test.C.this field s must be initialized in constructor" suggested that. I was wrong.
You were right, it does. You just cannot default construct C if S cannot be default constructed. This works: struct S { disable this(); this(int x) { } } class C { S s; this(int) { s = S(42); // comment out this line and it does not compile } } void main() { auto c = new C(0); } And that implies that the 'feature' of infectious default constructor disabling for classes is worthless. But it makes perfect sense for structs.
Sep 12 2011
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 11 Sep 2011 19:57:12 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case

 struct S
 {
  disable this();
 this(int x)
 {
 }
 }

 class C
 {
 S s;
 this()
 {
 s = S(42);
 }
 }

 void main()
 {
 auto c = new C;
 }

 yields Error: default construction is disabled for type C

 Is it a bug?
No, it's a feature!
Surely this must be a mistake. A class's constructor is always called when it is created, and for non-default constructors, an uninitialized value with disable this() is detected. There *needs* to be a way to re-enable default construction for classes containing structs with disabled default constructors. If this is simply something that is not yet done, that's fine. -- Simen
Sep 12 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 11 Sep 2011 13:57:12 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 9/11/2011 9:08 AM, Max Samukha wrote:
 This test case

 struct S
 {
  disable this();
 this(int x)
 {
 }
 }

 class C
 {
 S s;
 this()
 {
 s = S(42);
 }
 }

 void main()
 {
 auto c = new C;
 }

 yields Error: default construction is disabled for type C

 Is it a bug?
No, it's a feature!
While I agree a nested " disable this" struct inside a struct should disable default construction of the outer struct, a class *requires* initialization, and a default constructor is called explicitly (and can be defined!) We are talking two different worlds here. I think the above should be accepted. I'm not sure how feasible it is, since it requires code path analysis. -Steve
Sep 12 2011
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 While I agree a nested " disable this" struct inside a struct should  
 disable default construction of the outer struct, a class *requires*  
 initialization, and a default constructor is called explicitly (and can  
 be defined!)  We are talking two different worlds here.

 I think the above should be accepted.  I'm not sure how feasible it is,  
 since it requires code path analysis.
What do you mean analysis? What's needed is checking 'did this class explicitly implement a default ctor?'. Te other test ('is the struct properly initialized?' is already performed for other constructors, so should pose no huge impediment. -- Simen
Sep 12 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Sep 2011 10:50:49 -0400, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 While I agree a nested " disable this" struct inside a struct should  
 disable default construction of the outer struct, a class *requires*  
 initialization, and a default constructor is called explicitly (and can  
 be defined!)  We are talking two different worlds here.

 I think the above should be accepted.  I'm not sure how feasible it is,  
 since it requires code path analysis.
What do you mean analysis? What's needed is checking 'did this class explicitly implement a default ctor?'. Te other test ('is the struct properly initialized?' is already performed for other constructors, so should pose no huge impediment.
I mean the compiler has to verify a constructor is called for the member struct in the class constructor. You also must define a constructor of some kind (does not have to be a no-arg ctor), because the compiler generated default constructor cannot call the default constructor of the struct. Maybe it's easy, but I have no idea, hence "I'm not sure" :) -Steve
Sep 12 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/12/2011 05:10 PM, Steven Schveighoffer wrote:
 On Mon, 12 Sep 2011 10:50:49 -0400, Simen Kjaeraas
 <simen.kjaras gmail.com> wrote:

 On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 While I agree a nested " disable this" struct inside a struct should
 disable default construction of the outer struct, a class *requires*
 initialization, and a default constructor is called explicitly (and
 can be defined!) We are talking two different worlds here.

 I think the above should be accepted. I'm not sure how feasible it
 is, since it requires code path analysis.
What do you mean analysis? What's needed is checking 'did this class explicitly implement a default ctor?'. Te other test ('is the struct properly initialized?' is already performed for other constructors, so should pose no huge impediment.
I mean the compiler has to verify a constructor is called for the member struct in the class constructor. You also must define a constructor of some kind (does not have to be a no-arg ctor), because the compiler generated default constructor cannot call the default constructor of the struct. Maybe it's easy, but I have no idea, hence "I'm not sure" :) -Steve
The compiler already checks that for non-default class constructors, so the change would probably be very easy to carry out.
Sep 12 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, September 12, 2011 21:02:52 Timon Gehr wrote:
 On 09/12/2011 05:10 PM, Steven Schveighoffer wrote:
 On Mon, 12 Sep 2011 10:50:49 -0400, Simen Kjaeraas
 
 <simen.kjaras gmail.com> wrote:
 On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer
 
 <schveiguy yahoo.com> wrote:
 While I agree a nested " disable this" struct inside a struct should
 disable default construction of the outer struct, a class *requires*
 initialization, and a default constructor is called explicitly (and
 can be defined!) We are talking two different worlds here.
 
 I think the above should be accepted. I'm not sure how feasible it
 is, since it requires code path analysis.
What do you mean analysis? What's needed is checking 'did this class explicitly implement a default ctor?'. Te other test ('is the struct properly initialized?' is already performed for other constructors, so should pose no huge impediment.
I mean the compiler has to verify a constructor is called for the member struct in the class constructor. You also must define a constructor of some kind (does not have to be a no-arg ctor), because the compiler generated default constructor cannot call the default constructor of the struct. Maybe it's easy, but I have no idea, hence "I'm not sure" :) -Steve
The compiler already checks that for non-default class constructors, so the change would probably be very easy to carry out.
I think that the problem is that the compiler needs to guarantee that the constructor actually initializes the member variable which can't be default constructed. But since it already has to do that with immutable constructors, that's probably not all that diffucult a change either. - Jonathan M Davis
Sep 12 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/13/2011 12:09 AM, Jonathan M Davis wrote:
 On Monday, September 12, 2011 21:02:52 Timon Gehr wrote:
 On 09/12/2011 05:10 PM, Steven Schveighoffer wrote:
 On Mon, 12 Sep 2011 10:50:49 -0400, Simen Kjaeraas

 <simen.kjaras gmail.com>  wrote:
 On Mon, 12 Sep 2011 16:43:36 +0200, Steven Schveighoffer

 <schveiguy yahoo.com>  wrote:
 While I agree a nested " disable this" struct inside a struct should
 disable default construction of the outer struct, a class *requires*
 initialization, and a default constructor is called explicitly (and
 can be defined!) We are talking two different worlds here.

 I think the above should be accepted. I'm not sure how feasible it
 is, since it requires code path analysis.
What do you mean analysis? What's needed is checking 'did this class explicitly implement a default ctor?'. Te other test ('is the struct properly initialized?' is already performed for other constructors, so should pose no huge impediment.
I mean the compiler has to verify a constructor is called for the member struct in the class constructor. You also must define a constructor of some kind (does not have to be a no-arg ctor), because the compiler generated default constructor cannot call the default constructor of the struct. Maybe it's easy, but I have no idea, hence "I'm not sure" :) -Steve
The compiler already checks that for non-default class constructors, so the change would probably be very easy to carry out.
I think that the problem is that the compiler needs to guarantee that the constructor actually initializes the member variable which can't be default constructed. But since it already has to do that with immutable constructors, that's probably not all that diffucult a change either. - Jonathan M Davis
Yes, that is what I meant. It already does that: struct S{ this() disable; } class C{ S s; this(){} // Error: constructor tt.C.this field s must be initialized in constructor } The only thing that needs to be changed is that classes containing non-default-constructible uninitialized fields can be default constructed if they provide a default constructor.
Sep 12 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Sep 2011 20:44:26 -0400, Timon Gehr <timon.gehr gmx.ch> wrote:

 Yes, that is what I meant. It already does that:

 struct S{
      this()  disable;
 }

 class C{
      S s;
      this(){} // Error: constructor tt.C.this field s must be  
 initialized in constructor
 }

 The only thing that needs to be changed is that classes containing  
 non-default-constructible uninitialized fields can be default  
 constructed if they provide a default constructor.
Oh wow, this really is a no-brainer. Walter? At least there should be an enhancement report. -Steve
Sep 14 2011