On Fri, 5 Apr 2013, Dmitry A. Kazakov wrote: > On Fri, 5 Apr 2013 17:16:59 +0200, Stefan.Lucks@uni-weimar.de wrote: >> I agree with you that there is no reason to distinguish between them. The >> entire distinction narrow, Wide_ and Wide_Wide_ Strings (and Characters) >> is a historical artifact, no more, no less. >> >> But if there is no reason to disting between them -- there is no reason to >> mix them either! > > Sorry, but it cannot be both. No, if you mix them, you must distinguish them. At least, when implementing your own multi-method, such as function Longest_Common_Substring(S1, S2: Universal_String) return Universal_String; -- maybe "is abstract"; Either Universal_String is abstract, then so would be this multi-method, and you would to override it n^3 times, when supporting n different string types. Or you can actually have objects of type Universal_String, but then using this method without making explicit conversions means a whole new bunch of implicit conversions. One problem with implicit conversions is that Strings don't "know" their encoding (Is it UTF-8? Or ISO-Latin-1? Or ...?), so you don't even have the information you need to perform the conversion. Which is why you need to make explicit conversions. And then it is not a big leap to say "convert everything into my favourite kind of string, then call my method, and then convert the result back". > Consider Ada.Text_IO.Create. It has name a string and content. You tell > us that it is not necessary to be able to open an UTF-8 file which name > is UTF-16? Blame Microsoft. I know a lot of things to blame Microsoft for, but in the Unix world, all files are essentially sequences of bytes that you read or write, and it is your problem to know the semantic of these sequences. So this is not much better than in the Microsoft world. In any case, Ada.Text_IO.Create is a good example. As much as I understand you, if Name is of type Universal_String'Class and you call Ada.Text_IO.Create(File, Name) you expect the proper thing to happen, right? I agree that this would be cool. But it just cannot work! Right now, if the encoding of Name is, say, ISO-Latin-1 and the encoding the underlying filesystem expects is UTF-8, you can have really surprising results when calling Ada.Text_IO.Create(File, Name). It would be cool to solve this issue with some Universal_String type. But firstly, the strings we have don't know their encoding. The application programmer knows (hopefully), but it is not part of String. Secondly, even if we had some kind of enhanced string type with object Name storing its own encoding, in addition to the string itself, the library wouldn't know which encoding it to convert Name into, or if any conversion is needed at all! The point is, you can mount different filesystems with different naming and encoding conventions, even on the same machine. (With Linux for sure, I guess that also works in the Microsoft world.) No Universal_ type will solve this issue -- you just cannot get rid of explicit conversions. At the end of the day, something such as opening or creating a file is some kind of a low-level operation, alas. >> I think, I agree with Randy here. The old bunch of strings are a mess, > > There is nothing wrong with them except for being not in the same class. > [Literals could be done better] > Furthermore what Randy proposes will actually be worse than pitiful > Unbounded_String. For them you could at least do this: > > type Relative_File_Path is new Unbounded_String; > type Absolute_File_Path is new Unbounded_String; > > You could not do that for tagged strings. OK, here we agree. Whatever the "new" strings are, the ability to define incompatible types with the same representation, that you cannot mix (without explicit conversion) is important for a language supporting safety-critical stuff! I sometimes have types Tainted_String and Save_String, being both derived from [Wide_[Wide_]]String, and I am happy when the compiler stops me from messing up between variables of this type. Does Randy's proposal really not allow that? ------ I love the taste of Cryptanalysis in the morning! ------ --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--