September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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?
|
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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.
|
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
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 |
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to d coder | "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. |
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | "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. |
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | "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. |
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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 |
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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... |
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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.
|
September 08, 2011 Re: dmd 1.070 and 2.055 release | ||||
---|---|---|---|---|
| ||||
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
|
Copyright © 1999-2021 by the D Language Foundation