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