What's left for 1.0?

[Olli Aalto]

Daniel Keep wrote:
> Imagine you compile the standard library with -version=UTF8.  Let's take
> the following function:
> 

How about if the standard library didn't use string? So it would still 
have 3 versions of find for example?

>> int find(string s, dchar c) { ... }
> 
> This would be compiled as:
> 
>> int find(char[] s, dchar c) { ... }
> 
> You then write some code to use that:
> 
>> ...
>> string attr = "key:value";
>> ...
>> auto pos = find(attr, ':');
>> ...
> 

Something like this:

int find(char[], char c) { ... }
int find(wchar[], wchar c) { ... }
int find(dchar[], dchar c) { ... }

void foo()
{
   string attr = "key:value";
   ...
   auto pos = find(attr, ':');
   ...
}

Wouldn't that link properly?

Hmm...

Probably not good enough. This whole idea is based on the assumption 
that the application writer knows the environment where and how his/her 
application will be used. If the application was compiled as UTF-8 and 
it gets a UTF-32 character as input, it would not be very good? Would 
the coder be required to put all the input through std.utf.toUTF8()?
Or is that something that should be done even now?
Well, you all seem to be smart people so I'm content to wait for 
whatever you come up with. :)

> For whatever reason, your program will run optimally using UTF-32.
> 
>> dmd -version=UTF32 app.d
> 
> But that means that in the standard library, "string" is really
> "char[]", and in your program it's "dchar[]".  You try to link against
> the standard library, and the linker barfs (quite correctly) since the
> function you're using doesn't exist.
> 
> It's a nice idea, but with the current object formats, and the way
> conditional compilation works, I don't think it's actually possible.
> 

Yes, I got the feeling that it was a little too simple. :)

Personally I think I'll stick mostly to dchar[]s in real applications 
and char[]s in test programs. Memory is cheap enough these days that it 
doesn't matter to me right now.

O.