"Carlos Santander B." <carlos8294@msn.com> wrote in message news:bjjfel$2ndu$1@digitaldaemon.com...
> Walter escribió:
> >
> > While D supports unicode source files, unicode comments, unicode
strings,
> > and generating unicode apps, the identifiers are standard C identifiers. This ensures compatibility with existing linkers, librarians, debuggers, disassemblers, etc. Rewriting all of that stuff is way, way beyond the
scope
> > of D!
> Is there a way to change that?

Not with the resources at my disposal. Sorry.

Walter wrote:
> "Carlos Santander B." <carlos8294@msn.com> wrote in message
> news:bjjfel$2ndu$1@digitaldaemon.com...
> 
>>Walter escribió:
>>
>>>While D supports unicode source files, unicode comments, unicode
> 
> strings,
> 
>>>and generating unicode apps, the identifiers are standard C identifiers.
>>>This ensures compatibility with existing linkers, librarians, debuggers,
>>>disassemblers, etc. Rewriting all of that stuff is way, way beyond the
> 
> scope
> 
>>>of D!
>>
>>Is there a way to change that?
> 
> 
> Not with the resources at my disposal. Sorry.
> 

isn't utf8 designed for exactly this purpose ?
would the linker fail if the ids contained chars 0x80..0xFF ? Java utf8 encoding only uses 0x01..0xFE (or 0xFD [i forget which]) so strings can have embedded nulls and oxFF's but they never appear in the "exported" string.

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjkod7$1jt5$1@digitaldaemon.com...
> isn't utf8 designed for exactly this purpose ?
> would the linker fail if the ids contained chars 0x80..0xFF ? Java utf8
> encoding only uses 0x01..0xFE (or 0xFD [i forget which]) so strings can
> have embedded nulls and oxFF's but they never appear in the "exported"
> string.

The identifier strings will print as garbage, though.