[dmd-beta] Time for a new beta?

[Dmitry Olshansky]

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:
>
> 1. My Windows SDK conversion tool converts C macros to templates, e.g.
>
> #define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
>
> is converted to
>
> auto MAKEINTRESOURCEW(ARG)(ARG i)() { return ( cast(LPWSTR)( 
> cast(ULONG_PTR)( cast(WORD)(i)))); }
>
> This no longer works for CTFE, because casts to pointers are no longer 
> allowed. Making the argument a template parameter still works, though:
>
> auto MAKEINTRESOURCEW(int i)() { return ( cast(LPWSTR)( 
> cast(ULONG_PTR)( cast(WORD)(i)))); }
>
> Also, casting to a pointer is still allowed when initializing a global 
> variable at compile time.
>
> Is this by design or a regression?
>
> 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]*)$".


> 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. The 
embarrassing part comes from the fact that I actually picked up this 
foreach trick from original std.regex.

> Maybe it would be better to wait with deprecating std.regexp until 
> there is a working alternative.
>
Given this fresh bug in std.regex I'd naturally agree.

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

> Otherwise, it seems the generated executable works fine.
>
> Rainer
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta


-- 
Dmitry Olshansky