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;

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.

Hacked up in two minutes to upgrade dwinproj http://codepad.org/gasNWPoK

Worked fine for all but one of ~200 modules, yay.

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;

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.

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...

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:).

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. :)

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.

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