In article <ce2gk5$l00$1@digitaldaemon.com>, Walter says...

>I'd already added it to my todo list, Jill <g>. But these things sometimes have hidden gotchas, so I wanted to let it simmer for a bit. I've put in stuff too quickly before, and had to back it out later :-(

Fair enough. No hurry. I'm sure we're all in agreement that more important bug-fixes should come first.

Keep up the good work. :)

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ce2onb$pug$1@digitaldaemon.com...
> Fortunately, since D syntax requires that the first character of a D
source file
> /must/ be an ASCII character, detecting the encoding is quick and easy.

Yes, and that's a key insight that I'd missed. Thanks!

Walter wrote:
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
> news:ce2due$jos$1@digitaldaemon.com...
> 
>>Come on, that's a /tiny/ function, and I've written it all for you. The
>>"overhead" is to call it /once/ during the source text stage (and that's
>>/instead of/, not as well as, the current detection routine). As its
> 
> I'd already added it to my todo list, Jill <g>. But these things sometimes
> have hidden gotchas, so I wanted to let it simmer for a bit. I've put in
> stuff too quickly before, and had to back it out later :-(

Okay, I agree that the overhead is non-existent.

This may be a potential "gotcha" (but I don't know how significant it is): Walter implements this detection routine, but D compilers from other vendors don't. Then there would be D files that only compile on DMD. To prevent this from happening, the new Unicode detection algortithm needs to be explicit in the D spec.

James McComb