On Saturday, August 20, 2011 10:39:22 Rainer Schuetze wrote:
> 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).
> 
> I think this was discussed before, but I'm not sure what the conclusion
> was. I suggest adding some forwarding aliases to std.uni for function
> that have identical implementation, and ensure that the compiler does
> not complain about ambiguities if these are just aliases to the same symbol.

All calls to functions in std.ctype should be replaced either with functions in std.ascii or functions std.uni. Functions with the identical names do the same thing except that those in std.uni operate on unicode, and those in std.ascii only operate on ascii (they still work with unicode characters; they just ignore them). If you need to use both std.ascii and std.uni, then you need to fully qualify them - e.g. std.ascii.isUpper or std.uni.isAlpha - or you need to create aliases for them.

- Jonathan M Davis

On Saturday, August 20, 2011 18:10:01 Nick Sabalausky wrote:
> From: "Dmitry Olshansky" <dmitry.olsh at gmail.com>
> 
> > On 20.08.2011 12:39, Rainer Schuetze wrote:
> >> 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).
> >> 
> >> I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same symbol.
> > 
> > Recalling last discussion on this, the users have to solve this on their own. Be it use unicode everywhere or full std.ascii.xxx/std.uni.xxx or whatever. I ended up using renamed imports.
> 
> There's a simple alias trick that works very well for that sort of thing:
> 
> ------------------------
> module m1;
> void a() {};
> void b() {};
> ------------------------
> module m2;
> void b() {};
> void c() {};
> ------------------------
> module main;
> import m1
> import m2;
> 
> // Nifty trick: Pull m1's b() into local scope,
> // effectively"prioritizing" it.
> private alias m1.b b;
> 
> void main() {
>     b(); // Works: Calls m1.b()
> }
> ------------------------

In theory, that's a great solution, but it doesn't work right now:

http://d.puremagic.com/issues/show_bug.cgi?id=6013

- Jonathan M Davis

On Sat, Aug 20, 2011 at 5:02 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On Saturday, August 20, 2011 10:39:22 Rainer Schuetze wrote:
> > 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit,
> etc.).
> >
> > I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same
> symbol.
>
> All calls to functions in std.ctype should be replaced either with
> functions
> in std.ascii or functions std.uni. Functions with the identical names do
> the
> same thing except that those in std.uni operate on unicode, and those in
> std.ascii only operate on ascii (they still work with unicode characters;
> they
> just ignore them). If you need to use both std.ascii and std.uni, then you
> need to fully qualify them - e.g. std.ascii.isUpper or std.uni.isAlpha - or
> you need to create aliases for them.


On a somewhat related note, I wonder if this pull request could get reviewed
in the near future (and hopefully a fix could make it into the next
version):
https://github.com/D-Programming-Language/dmd/pull/190
(Fixes selective and renamed imports without having to touch overload
resolution in the way discussed via email.)

This is probably the single most painful bug in DMD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110820/1cb5b04d/attachment.html>

From: "Andrej Mitrovic" <andrej.mitrovich at gmail.com>
> On 8/21/11, Nick Sabalausky <bus_dmdbeta at semitwist.com> wrote:
>> // Nifty trick: Pull m1's b() into local scope,
>> // effectively"prioritizing" it.
>> private alias m1.b b;
>
> I do this all the time since I'm getting symbol clashes between libraries every day, unfortunately. I never thought about the private vs public thing though, this completely slipped my mind.

I've been using it too, but I didn't think of the public/private issue either until I was just typing up that message :P

On Saturday, August 20, 2011 18:02:15 Andrew Wiley wrote:
> On Sat, Aug 20, 2011 at 5:02 PM, Jonathan M Davis
<jmdavisProg at gmx.com>wrote:
> > On Saturday, August 20, 2011 10:39:22 Rainer Schuetze wrote:
> > > 3. I tried to remove some more (currently soft) deprecation messages
> > > regarding std.ctype, and it turned out that it was a bit of a hassle
> > > to
> > > get it to compile because I had to mix both std.ascii and std.uni.
> > > This
> > > is happening because I'd like to use the isAlpha from std.uni, but
> > > there are other functions missing from std.uni (like isDigit,
> > > isHexDigit,>
> > etc.).
> > 
> > > I think this was discussed before, but I'm not sure what the
> > > conclusion
> > > was. I suggest adding some forwarding aliases to std.uni for
> > > function
> > > that have identical implementation, and ensure that the compiler
> > > does
> > > not complain about ambiguities if these are just aliases to the same
> > 
> > symbol.
> > 
> > All calls to functions in std.ctype should be replaced either with
> > functions
> > in std.ascii or functions std.uni. Functions with the identical names do
> > the
> > same thing except that those in std.uni operate on unicode, and those in
> > std.ascii only operate on ascii (they still work with unicode
> > characters;
> > they
> > just ignore them). If you need to use both std.ascii and std.uni, then
> > you need to fully qualify them - e.g. std.ascii.isUpper or
> > std.uni.isAlpha - or you need to create aliases for them.
> 
> On a somewhat related note, I wonder if this pull request could get reviewed
> in the near future (and hopefully a fix could make it into the next
> version):
> https://github.com/D-Programming-Language/dmd/pull/190
> (Fixes selective and renamed imports without having to touch overload
> resolution in the way discussed via email.)
> 
> This is probably the single most painful bug in DMD.

That depends on Walter. I don't know what his process is for going through pull requests. He'll get to it eventually, but I have no idea when.

- Jonathan M Davis

On 20.08.2011 11:40, Dmitry Olshansky wrote:
> On 20.08.2011 12:39, Rainer Schuetze wrote:
>> Hi,
>>
>> I recently updated to the latest revision from github and tried to compile my main project visuald with it. Here are some complications that have hit me:
>>
>> [...]
>> 2. std.regexp is deprecated now, which is good, because there is no
>> reason to have two different implementations of regular expressions.
>> Unfortunately, std.regex seems to have some problems with rather
>> simple regular expressions like r"^(.*)\(([0-9]+)\):(.*)$" that is
>> supposed to match error messages like "file.d(37): huhu". std.regexp
>> worked for this expression.
>>
> That's most likely my fault, since there is a special casing for .* in std.regex which very well might be at fault here. Honestly, at a certain point I just gave up on trying to fix current std.regex, apparently a bit early. A quick test on this  would be r"^([\x00-\x80]*)\(([0-9]+)\):([\x00-\x80]*)$".
>

Thanks for confirming. Your workaround works for this regular expression. But I also have a user input field that can be a regular expression, where ".*" would be nice to work out of the box. I could replace it with the range as a workaround, though.

>
>> Dmitry Olshansky's new std.regex also works, but it does not compile with warnings enabled (even not with -wi) ( http://d.puremagic.com/issues/show_bug.cgi?id=6518 ).
>>
> Btw I thought -wi is supposed to just list it as  warning.

I thought so, too. But the check is only done when warnings are enabled, but an error is issued instead of a warning (statement.c, line 676).

On 21.08.2011 00:10, Nick Sabalausky wrote:
> From: "Dmitry Olshansky" <dmitry.olsh at gmail.com>
>> On 20.08.2011 12:39, Rainer Schuetze wrote:
>>> 3. I tried to remove some more (currently soft) deprecation messages regarding std.ctype, and it turned out that it was a bit of a hassle to get it to compile because I had to mix both std.ascii and std.uni. This is happening because I'd like to use the isAlpha from std.uni, but there are other functions missing from std.uni (like isDigit, isHexDigit, etc.).
>>>
>>> I think this was discussed before, but I'm not sure what the conclusion was. I suggest adding some forwarding aliases to std.uni for function that have identical implementation, and ensure that the compiler does not complain about ambiguities if these are just aliases to the same symbol.
>>>
>> Recalling last discussion on this, the users have to solve this on their own. Be it use unicode everywhere or full std.ascii.xxx/std.uni.xxx or whatever. I ended up using renamed imports.
>>
>
> There's a simple alias trick that works very well for that sort of thing:
>
> ------------------------
> module m1;
> void a() {};
> void b() {};
> ------------------------
> module m2;
> void b() {};
> void c() {};
> ------------------------
> module main;
> import m1
> import m2;
>
> // Nifty trick: Pull m1's b() into local scope,
> // effectively"prioritizing" it.
> private alias m1.b b;
>
> void main() {
>    b(); // Works: Calls m1.b()
> }
> ------------------------
>

I'm not too happy with that solution:
- you have to add these aliases in every module with ambiguities.
- you get even more ambiguities if you import the module with the
additional aliases. Even if private were working as specified, overload
resolution happens before protection checks (which does not seem like
the best idea to start with).

I've used a combination of selective imports and full module specification for now.

Thanks,
Rainer

On Sunday 21 August 2011 09:36 Rainer Schuetze wrote:
> I've used a combination of selective imports

Be careful with that

private import m : a;

is the same as

private import m;
alias m.a a;

atm. Meaning that if you import that file, m.a will be visible as a from the outside.

On Sunday, August 21, 2011 10:16:42 Christian Kamm wrote:
> On Sunday 21 August 2011 09:36 Rainer Schuetze wrote:
> > I've used a combination of selective imports
> 
> Be careful with that
> 
> private import m : a;
> 
> is the same as
> 
> private import m;
> alias m.a a;
> 
> atm. Meaning that if you import that file, m.a will be visible as a from the outside.

All imports are private unless marked public, so there's no need for the private there. But selective imports _are_ buggy at the moment.

http://d.puremagic.com/issues/show_bug.cgi?id=5161

But it's worse that it creating a public alias. A don't believe that a public alias will conflict with what it's an alias for. However, selective imports currently create whole new symbols, so they _do_ conflict. Hopefully, the issue gets fixed soon.

- Jonathan M Davis

On 21.08.2011 10:36, Jonathan M Davis wrote:
> On Sunday, August 21, 2011 10:16:42 Christian Kamm wrote:
>> On Sunday 21 August 2011 09:36 Rainer Schuetze wrote:
>>> I've used a combination of selective imports
>> Be careful with that
>>
>> private import m : a;
>>
>> is the same as
>>
>> private import m;
>> alias m.a a;
>>
>> atm. Meaning that if you import that file, m.a will be visible as a from the outside.
> All imports are private unless marked public, so there's no need for the private there. But selective imports _are_ buggy at the moment.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5161
>
> But it's worse that it creating a public alias. A don't believe that a public alias will conflict with what it's an alias for. However, selective imports currently create whole new symbols, so they _do_ conflict. Hopefully, the issue gets fixed soon.

Good to know, thanks. I just verified that an alias does not generate an conflict with the symbol it is aliased to.