On Sun, 22 Aug 2004 16:29:29 -0700, antiAlias <fu@bar.com> wrote:
> Right. But I don't think this stuff should be done by a cast(). I mean, you
> can just as easily convert them "manually" using the functions in utf.d,
> can't you?

Yep, we want implicit conversion, eg.

char[] a = "abc";
dchar[] b = a;     <- does a UTF-8 to UTF-32

> Where automated conversion would really help is in stringizing
> (the original topic; I think):

Definately.

> class A {}
>
> int x;
> long y;
> dchar[] z;
> A a = new A;
>
> char[] narrow = "string some stuff together " ~ z ~ y ~ x ~ a;
>
> and the wide version:
>
> dchar[] wide = "string some stuff together " ~ z ~ y ~ x ~ a;
>
> If the ~ concatenators could convert between dchar[] and char[]
> appropriately, then Matthew's idea about the type being specified by the
> left-hand side would probably work. Though, on reflection, this seem like an
> awful lot of work for an operator to perform. Particularly so when it's a
> special-case, as it is here (e.g. int[] does not does anything fancy like
> this).

The operator itself doesn't do the work, it's the type promotion system, eg when you say

int a;
float b,c;

c = b+a;

the compiler first promotes 'a' to float, then adds them, then assigns that to 'c'.

So, Matthews idea effects the type promotion system, I had a similar idea, I suggested the type promotion system use the type of the thing being assigned to (c in the above) to determine what to promote the type to. This was to solve the common:

float percentage;
int value,total;

percentage = value/total*100;

bug which only ever assigns percentage an integral value as value,total and 100 are integral.
To fix the above you must go

cast(float)value/cast(float)total*100.0

notice the casts and the .0 on the 100, this makes them all floats, which is the type of the result.


I think we want/need two things:
 - implicit calling of toString for types with toString defined.
 - implicit calling of toString for basic types.
 - type promotion in operators to cause implicit conversion between UTF-x types.

Such that the example:

# char[] narrow = "string some stuff together " ~ z ~ y ~ x ~ a;

Will cause:

- represent "string.." in UTF-32
- append z
- call y.toString(), convert to UTF-32, append
- call x.toString(), convert to UTF-32, append
- call a.toString(), convert to UTF-32, append
- convert to UTF-8, assign to narrow.

If the example were changed to:

# char[] narrow = cast(char[])"string some stuff together " ~ z ~ y ~ x ~ a;

then the operations would be:

- represent "string.." in UTF-8
- convert z to UTF-8, append
- call y.toString(), append
- call x.toString(), append
- call a.toString(), append
- assign to narrow

which is better as less conversions are required. This is in essence what Matthews idea causes, yes?

My suggestion causes the same sequence of events as Matthews idea.

The other example:

# dchar[] wide = "string some stuff together " ~ z ~ y ~ x ~ a;

probably causes:

- represent "string.." as UTF-32
- append z
- call y.toString(), convert to UTF-32, append
- call x.toString(), convert to UTF-32, append
- call a.toString(), convert to UTF-32, append
- assign to wide

interestingly this is identical to the first example, if we take Matthews idea into account we get:

- represent "string.." as UTF-8
- convert z to UTF-8, append
- call y.toString(), append
- call x.toString(), append
- call a.toString(), append
- convert to UTF-32, assign to wide

which is better, my idea actually causes the original behaviour :(

> Instead, how about a concat(...) method? It's not hard to make a typesafe
> one that can do whatever conversion one desires (including calling
> toString() and converting as necessary). Hell; you could have two concat()
> methods: one for a dchar[] result and one for a char[] result.
>
> return "my granny is "~age~" old";
>
> becomes
>
> return concat ("my granny is ", age, " old");
>
> Is that really so awful?

Not awful, but IMO it's better if we don't need one.

> Regardless; I think there's still an issue about toString() not handling
> dchar[]. Although you can utf8 encode the content, that's hardly a
> convenience, or exactly efficient.

Exactly, so why not implicitly convert.. I can't see what problems it causes, and it certainly solves several.

Regan

> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsc5nxehm5a2sq9@digitalmars.com...
>> On Sun, 22 Aug 2004 10:11:10 +0000 (UTC), Arcane Jill
>> <Arcane_member@pathlink.com> wrote:
>> > In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says...
>> >>
>> >> The problems with that particular approach are twofold:
>> >>
>> >> 2) more importantly: it doesn't work for unicode strings, because
>> >> providing
>> >> a "dchar toString()" in each class is not covariant with the "char
>> >> toString()" living in the root Object. I wish there was an nice, 
>> clean,
>> >> elegant solution to this ...
>> >
>> > I've wondered about that myself, but I guess having toString() return
>> > char[] is
>> > not so bad. The magic of UTF-8 does, after all, allow us to store 
>> every
>> > character in a char[] (even though not in a char).
>> >
>> > But it would be really, really, /really/ cool, if all string types 
>> would
>> > *implicitly* cast to one another, *and* go through the relevant 
>> std.utf
>> > conversion routine to do so. Then classes could implement any of the
>> > following
>> > at their choice:
>> >
>> > #    char[] toString();
>> > #    wchar[] toString();
>> > #    dchar[] toString();
>> >
>> > Walter has opposed the notion that even /explicit/ casts from string 
>> to
>> > string
>> > should not do any conversion. I suggest:
>>
>> I believe Walters opposition was due to the fact that a conversion would
>> create inconsistency between string types and ubyte etc, also that the
>> ability to 'paint' one type as another is desired.
>>
>> I think the fact that char, wchar, and dchar have a specified encoding
>> sets them apart from other types, this fact makes painting one string type
>> to another completely useless, I cannot think of a reason to paint a
>> char[], wchar[] or dchar[] to each other? can you?
>>
>> If you can then I suggest something like:
>>
>> > #    c = cast(char[]) cast(void[]) d;  // does not call toUTF8()
>>
>> will suffice.
>>
>> It *does* make sense to paint char[], wchar[] or dchar[] as ubyte[] or
>> void[] etc so what I suggest is that conversion does occur, but, only if
>> both the source type and destination type have a specified encoding, i.e.
>> char, wchar and dchar to char, wchar or dchar.
>>
>> In conclusion I cannot see any valid reason not to make this change, I
>> believe it makes string handling:
>>   - simpler
>>   - more consistent
>>   - less error prone
>>
>> This change would make a string class totally useless, which I believe was
>> Walters original intention when creating these types.
>>
>> Regan
>>
>> --
>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Thinking about this some more, I have a feeling that D would solve a few problems if it were to support methods for the basic data types:

uint.toString()
uint.opCat()
uint.whatever()

char[].toString()
char[].opCat()
char[].whatever()

dchar[].opCat()
...

Think of them like properties. The useful thing about such things is that they are overloadable. Thus a char[] might have:

opCat(dchar[])
opCat(int)
opCat(float)
...

and so on. An example implementation for char[] might be thus:

char[] opCat(int x)
{
    return toString() ~ x.toString();
}

char[] opCat (dchar[] x)
{
    return toString() ~ utf.toUtf8(x);
}

On the face of it, this would solve several problems:

1) easy, natural conversion of any data-type to char[] and dchar[]
2) concatenation of arbitrary data types is supported
3) conversion between char[], wchar[], and dchar[] can be performed by
specialized operators

The expression

return "my granny is "~age~" old";

would then be almost trivial for the compiler to support. Appending a class instance would utilize opCat_r() in the normal fashion. Of course, there's a problem with what the return value should be for uint.toString() ... char[]? wchar[]? dchar[]? There's bound to be a good way to resolve that ... or perhaps there is no type.toString(), and the conversion is performed explicitly by others?

(for char[])
char[] opCat(int x)
{
    return this ~ string.toString(x);
}

(for dchar[])
dchar[] opCat(int x)
{
    return this ~ string.toWideString(x);
}


Wasn't there another thread (ages ago) that mentioned something like this?




"antiAlias" <fu@bar.com> wrote in message news:cgba37$1e13$1@digitaldaemon.com...
> Right. But I don't think this stuff should be done by a cast(). I mean,
you
> can just as easily convert them "manually" using the functions in utf.d, can't you? Where automated conversion would really help is in stringizing (the original topic; I think):
>
> class A {}
>
> int x;
> long y;
> dchar[] z;
> A a = new A;
>
> char[] narrow = "string some stuff together " ~ z ~ y ~ x ~ a;
>
> and the wide version:
>
> dchar[] wide = "string some stuff together " ~ z ~ y ~ x ~ a;
>
> If the ~ concatenators could convert between dchar[] and char[] appropriately, then Matthew's idea about the type being specified by the left-hand side would probably work. Though, on reflection, this seem like
an
> awful lot of work for an operator to perform. Particularly so when it's a special-case, as it is here (e.g. int[] does not does anything fancy like this).
>
> Instead, how about a concat(...) method? It's not hard to make a typesafe
> one that can do whatever conversion one desires (including calling
> toString() and converting as necessary). Hell; you could have two concat()
> methods: one for a dchar[] result and one for a char[] result.
>
> return "my granny is "~age~" old";
>
> becomes
>
> return concat ("my granny is ", age, " old");
>
> Is that really so awful?
>
>
> Regardless; I think there's still an issue about toString() not handling dchar[]. Although you can utf8 encode the content, that's hardly a convenience, or exactly efficient.
>
>
>
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc5nxehm5a2sq9@digitalmars.com...
> > On Sun, 22 Aug 2004 10:11:10 +0000 (UTC), Arcane Jill
> > <Arcane_member@pathlink.com> wrote:
> > > In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says...
> > >>
> > >> The problems with that particular approach are twofold:
> > >>
> > >> 2) more importantly: it doesn't work for unicode strings, because
> > >> providing
> > >> a "dchar toString()" in each class is not covariant with the "char
> > >> toString()" living in the root Object. I wish there was an nice,
clean,
> > >> elegant solution to this ...
> > >
> > > I've wondered about that myself, but I guess having toString() return
> > > char[] is
> > > not so bad. The magic of UTF-8 does, after all, allow us to store
every
> > > character in a char[] (even though not in a char).
> > >
> > > But it would be really, really, /really/ cool, if all string types
would
> > > *implicitly* cast to one another, *and* go through the relevant
std.utf
> > > conversion routine to do so. Then classes could implement any of the
> > > following
> > > at their choice:
> > >
> > > #    char[] toString();
> > > #    wchar[] toString();
> > > #    dchar[] toString();
> > >
> > > Walter has opposed the notion that even /explicit/ casts from string
to
> > > string
> > > should not do any conversion. I suggest:
> >
> > I believe Walters opposition was due to the fact that a conversion would create inconsistency between string types and ubyte etc, also that the ability to 'paint' one type as another is desired.
> >
> > I think the fact that char, wchar, and dchar have a specified encoding sets them apart from other types, this fact makes painting one string
type
> > to another completely useless, I cannot think of a reason to paint a char[], wchar[] or dchar[] to each other? can you?
> >
> > If you can then I suggest something like:
> >
> > > #    c = cast(char[]) cast(void[]) d;  // does not call toUTF8()
> >
> > will suffice.
> >
> > It *does* make sense to paint char[], wchar[] or dchar[] as ubyte[] or void[] etc so what I suggest is that conversion does occur, but, only if both the source type and destination type have a specified encoding,
i.e.
> > char, wchar and dchar to char, wchar or dchar.
> >
> > In conclusion I cannot see any valid reason not to make this change, I
> > believe it makes string handling:
> >   - simpler
> >   - more consistent
> >   - less error prone
> >
> > This change would make a string class totally useless, which I believe
was
> > Walters original intention when creating these types.
> >
> > Regan
> >
> > --
> > Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>

antiAlias wrote:
> Thinking about this some more, I have a feeling that D would solve a few
> problems if it were to support methods for the basic data types:
> 
> uint.toString()
> uint.opCat()
> uint.whatever()
> 
> char[].toString()
> char[].opCat()
> char[].whatever()
> 
> dchar[].opCat()
> ...
> 
> Think of them like properties. The useful thing about such things is that
> they are overloadable. Thus a char[] might have:
> 
> opCat(dchar[])
> opCat(int)
> opCat(float)
> ...
> 
> and so on. An example implementation for char[] might be thus:
> 
> char[] opCat(int x)
> {
>     return toString() ~ x.toString();
> }
> 
> char[] opCat (dchar[] x)
> {
>     return toString() ~ utf.toUtf8(x);
> }
> 
> On the face of it, this would solve several problems:
> 
> 1) easy, natural conversion of any data-type to char[] and dchar[]
> 2) concatenation of arbitrary data types is supported
> 3) conversion between char[], wchar[], and dchar[] can be performed by
> specialized operators
> 
> The expression
> 
> return "my granny is "~age~" old";
> 
> would then be almost trivial for the compiler to support. Appending a class
> instance would utilize opCat_r() in the normal fashion. Of course, there's a
> problem with what the return value should be for uint.toString() ... char[]?
> wchar[]? dchar[]? There's bound to be a good way to resolve that ... or
> perhaps there is no type.toString(), and the conversion is performed
> explicitly by others?

I think, if D is going to go this route, it may as well make primitive types into full-blown structs.  They could even be defined in Phobos. (through some sort of name-mangling scheme.  Maybe extend the language so that @keyword is taken to be an identifier)

Primitive types in C# are handled this way, and it's pretty cool.  The "built-in" types are basically value-classes to which which special-case optimizations are applied.

 -- andy

In article <opsc5skbhm5a2sq9@digitalmars.com>, Regan Heath says...

>So, Matthews idea effects the type promotion system,

Matthew's idea?

Matthew said something like: "all implicit conversions are a bit dodgy". The notion of making string types interchangable was in fact...


>I had a similar idea,

..Regan's idea, resuggested by me, Jill, in the response to some comment or other about Object.toString().


>I suggested the type promotion system use the type of the thing being assigned to (c in the above) to determine what to promote the type to.

That's the ticket.


>This is in essence what Matthews idea causes, yes?
>
>My suggestion causes the same sequence of events as Matthews idea.

Then there was h3r3tic's idea: "how about adapting the $ token to convert anything to a string?". I've got confused now about which/whose idea you're now talking about.


>> Instead, how about a concat(...) method?

Sure. Let's call it opCat(). And while we're at it, let's give in an operator to
overload.  :)


Jill
(agreeing with Regan)

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgc036$1u5u$1@digitaldaemon.com...
> In article <opsc5skbhm5a2sq9@digitalmars.com>, Regan Heath says...
>
> >So, Matthews idea effects the type promotion system,
>
> Matthew's idea?
>
> Matthew said something like: "all implicit conversions are a bit dodgy". The notion of making string types interchangable was in fact...
>
>
> >I had a similar idea,
>
> ..Regan's idea, resuggested by me, Jill, in the response to some comment or other about Object.toString().
>
>
> >I suggested the type promotion system use the type of the thing being assigned to (c in the above) to determine what to promote the type to.
>
> That's the ticket.
>
>
> >This is in essence what
> >Matthews idea causes, yes?
> >
> >My suggestion causes the same sequence of events as Matthews idea.
>
> Then there was h3r3tic's idea: "how about adapting the $ token to convert anything to a string?". I've got confused now about which/whose idea you're now talking about.
>
>
> >> Instead, how about a concat(...) method?
>
> Sure. Let's call it opCat(). And while we're at it, let's give in an operator to
> overload.  :)

I think he meant my suggestion that sequences of ~ involving non string types should be implicitly translated to calls to ?X?.toString() for object types, and to std.string.toString() for scalar types. (I also suggested that structs do not have automatic conversion, and that's a good thing. Given what we're now realising about the non-orthogonal nature of the struct's intent, that seems more sage now than it did when I suggested it.)

On Mon, 23 Aug 2004 15:52:12 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgc036$1u5u$1@digitaldaemon.com...
>> In article <opsc5skbhm5a2sq9@digitalmars.com>, Regan Heath says...
>>
>> >So, Matthews idea effects the type promotion system,
>>
>> Matthew's idea?
>>
>> Matthew said something like: "all implicit conversions are a bit dodgy". The
>> notion of making string types interchangable was in fact...
>>
>>
>> >I had a similar idea,
>>
>> ..Regan's idea, resuggested by me, Jill, in the response to some comment or
>> other about Object.toString().
>>
>>
>> >I suggested the type promotion system use the type of the thing being
>> >assigned to (c in the above) to determine what to promote the type to.
>>
>> That's the ticket.
>>
>>
>> >This is in essence what
>> >Matthews idea causes, yes?
>> >
>> >My suggestion causes the same sequence of events as Matthews idea.
>>
>> Then there was h3r3tic's idea: "how about adapting the $ token to convert
>> anything to a string?". I've got confused now about which/whose idea you're now
>> talking about.
>>
>>
>> >> Instead, how about a concat(...) method?
>>
>> Sure. Let's call it opCat(). And while we're at it, let's give in an operator to
>> overload.  :)
>
> I think he meant my suggestion that sequences of ~ involving non string types should be implicitly translated to calls
> to ?X?.toString() for object types, and to std.string.toString() for scalar types. (I also suggested that structs do not
> have automatic conversion, and that's a good thing. Given what we're now realising about the non-orthogonal nature of
> the struct's intent, that seems more sage now than it did when I suggested it.)

Actually I was referring to this idea...

"then Matthew's idea about the type being specified by the
left-hand side would probably work."

posted by 'antiAlias'.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 23 Aug 2004 05:41:58 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:

> In article <opsc5skbhm5a2sq9@digitalmars.com>, Regan Heath says...
>
>> So, Matthews idea effects the type promotion system,
>
> Matthew's idea?
>
> Matthew said something like: "all implicit conversions are a bit dodgy". The
> notion of making string types interchangable was in fact...

No this one .. "then Matthew's idea about the type being specified by the
left-hand side would probably work." - antiAlias.

>> I had a similar idea,
>
> ..Regan's idea, resuggested by me, Jill, in the response to some comment or
> other about Object.toString().
>
>> I suggested the type promotion system use the type of the thing being
>> assigned to (c in the above) to determine what to promote the type to.
>
> That's the ticket.
>
>
>> This is in essence what
>> Matthews idea causes, yes?
>>
>> My suggestion causes the same sequence of events as Matthews idea.
>
> Then there was h3r3tic's idea: "how about adapting the $ token to convert
> anything to a string?". I've got confused now about which/whose idea you're now
> talking about.

I wasn't even aware of this idea :)

I think instead of requiring a token it should automatically call toString for any type it is trying to promote to a string.

>>> Instead, how about a concat(...) method?
>
> Sure. Let's call it opCat(). And while we're at it, let's give in an operator to
> overload.  :)

Don't we already have an opCat? and if not, why not?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <opsc7jczjt5a2sq9@digitalmars.com>, Regan Heath says...

>>>> Instead, how about a concat(...) method?
>>
>> Sure. Let's call it opCat(). And while we're at it, let's give in an
>> operator to
>> overload.  :)
>
>Don't we already have an opCat? and if not, why not?

Of course we do.

Regan, one thing you should know about my posts is that anything I mark with a smiley is something said with a sense of humor. (I know some folk like to put <g> at the end of every post, but I don't do that). So if you see a smiley from me, it denotes a joke. Similar can be said for any text sandwiched between pseudo-tags like <sarcasm>...</sarcasm> or <rant>...</rant>.

I guess I was just hoping you'd see the joke and laugh, but plain text is maybe too awkward a medium for that kind of thing.

Jill

I thought about trying to get around the toString() issue using opCat() and
opCat_r(). It /nearly/ works ... the nice thing about opCat() et. al. is
that they're not overriding anything (like toString) and therefore can have
pretty much any kind of argument and/or return value. For example:

class A
{
    dchar[] opCat (dchar[] x) {...}

    dchar[] opCat (char[] x) {...}

    dchar[] opCat (wchar[] x) {}

    dchar[] opCat (int x) {...}

    // plus the opCat_r() equivalents
}

This looked really promising! However, it all fell apart when trying to add a different return type:

   char[] opCat (char[] x) {...}

because D only looks at the method name and argument type, and ignores the return type. Therefore, a conflict occurs between two operators, and the compiler throws an error. Adopting a type promotion approach (as both yourself and Matthew have suggested) would probably have to fix this bugaboo.



"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc5skbhm5a2sq9@digitalmars.com...
> On Sun, 22 Aug 2004 16:29:29 -0700, antiAlias <fu@bar.com> wrote:
> > Right. But I don't think this stuff should be done by a cast(). I mean,
> > you
> > can just as easily convert them "manually" using the functions in utf.d,
> > can't you?
>
> Yep, we want implicit conversion, eg.
>
> char[] a = "abc";
> dchar[] b = a;     <- does a UTF-8 to UTF-32
>
> > Where automated conversion would really help is in stringizing
> > (the original topic; I think):
>
> Definately.
>
> > class A {}
> >
> > int x;
> > long y;
> > dchar[] z;
> > A a = new A;
> >
> > char[] narrow = "string some stuff together " ~ z ~ y ~ x ~ a;
> >
> > and the wide version:
> >
> > dchar[] wide = "string some stuff together " ~ z ~ y ~ x ~ a;
> >
> > If the ~ concatenators could convert between dchar[] and char[]
> > appropriately, then Matthew's idea about the type being specified by the
> > left-hand side would probably work. Though, on reflection, this seem
> > like an
> > awful lot of work for an operator to perform. Particularly so when it's
a
> > special-case, as it is here (e.g. int[] does not does anything fancy
like
> > this).
>
> The operator itself doesn't do the work, it's the type promotion system, eg when you say
>
> int a;
> float b,c;
>
> c = b+a;
>
> the compiler first promotes 'a' to float, then adds them, then assigns that to 'c'.
>
> So, Matthews idea effects the type promotion system, I had a similar idea, I suggested the type promotion system use the type of the thing being assigned to (c in the above) to determine what to promote the type to. This was to solve the common:
>
> float percentage;
> int value,total;
>
> percentage = value/total*100;
>
> bug which only ever assigns percentage an integral value as value,total
> and 100 are integral.
> To fix the above you must go
>
> cast(float)value/cast(float)total*100.0
>
> notice the casts and the .0 on the 100, this makes them all floats, which is the type of the result.
>
>
> I think we want/need two things:
>   - implicit calling of toString for types with toString defined.
>   - implicit calling of toString for basic types.
>   - type promotion in operators to cause implicit conversion between UTF-x
> types.
>
> Such that the example:
>
> # char[] narrow = "string some stuff together " ~ z ~ y ~ x ~ a;
>
> Will cause:
>
> - represent "string.." in UTF-32
> - append z
> - call y.toString(), convert to UTF-32, append
> - call x.toString(), convert to UTF-32, append
> - call a.toString(), convert to UTF-32, append
> - convert to UTF-8, assign to narrow.
>
> If the example were changed to:
>
> # char[] narrow = cast(char[])"string some stuff together " ~ z ~ y ~ x ~
> a;
>
> then the operations would be:
>
> - represent "string.." in UTF-8
> - convert z to UTF-8, append
> - call y.toString(), append
> - call x.toString(), append
> - call a.toString(), append
> - assign to narrow
>
> which is better as less conversions are required. This is in essence what Matthews idea causes, yes?
>
> My suggestion causes the same sequence of events as Matthews idea.
>
> The other example:
>
> # dchar[] wide = "string some stuff together " ~ z ~ y ~ x ~ a;
>
> probably causes:
>
> - represent "string.." as UTF-32
> - append z
> - call y.toString(), convert to UTF-32, append
> - call x.toString(), convert to UTF-32, append
> - call a.toString(), convert to UTF-32, append
> - assign to wide
>
> interestingly this is identical to the first example, if we take Matthews idea into account we get:
>
> - represent "string.." as UTF-8
> - convert z to UTF-8, append
> - call y.toString(), append
> - call x.toString(), append
> - call a.toString(), append
> - convert to UTF-32, assign to wide
>
> which is better, my idea actually causes the original behaviour :(
>
> > Instead, how about a concat(...) method? It's not hard to make a
typesafe
> > one that can do whatever conversion one desires (including calling
> > toString() and converting as necessary). Hell; you could have two
> > concat()
> > methods: one for a dchar[] result and one for a char[] result.
> >
> > return "my granny is "~age~" old";
> >
> > becomes
> >
> > return concat ("my granny is ", age, " old");
> >
> > Is that really so awful?
>
> Not awful, but IMO it's better if we don't need one.
>
> > Regardless; I think there's still an issue about toString() not handling dchar[]. Although you can utf8 encode the content, that's hardly a convenience, or exactly efficient.
>
> Exactly, so why not implicitly convert.. I can't see what problems it causes, and it certainly solves several.
>
> Regan
>
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc5nxehm5a2sq9@digitalmars.com...
> >> On Sun, 22 Aug 2004 10:11:10 +0000 (UTC), Arcane Jill
> >> <Arcane_member@pathlink.com> wrote:
> >> > In article <cg68tk$11on$1@digitaldaemon.com>, antiAlias says...
> >> >>
> >> >> The problems with that particular approach are twofold:
> >> >>
> >> >> 2) more importantly: it doesn't work for unicode strings, because
> >> >> providing
> >> >> a "dchar toString()" in each class is not covariant with the "char
> >> >> toString()" living in the root Object. I wish there was an nice,
> >> clean,
> >> >> elegant solution to this ...
> >> >
> >> > I've wondered about that myself, but I guess having toString() return
> >> > char[] is
> >> > not so bad. The magic of UTF-8 does, after all, allow us to store
> >> every
> >> > character in a char[] (even though not in a char).
> >> >
> >> > But it would be really, really, /really/ cool, if all string types
> >> would
> >> > *implicitly* cast to one another, *and* go through the relevant
> >> std.utf
> >> > conversion routine to do so. Then classes could implement any of the
> >> > following
> >> > at their choice:
> >> >
> >> > #    char[] toString();
> >> > #    wchar[] toString();
> >> > #    dchar[] toString();
> >> >
> >> > Walter has opposed the notion that even /explicit/ casts from string
> >> to
> >> > string
> >> > should not do any conversion. I suggest:
> >>
> >> I believe Walters opposition was due to the fact that a conversion
would
> >> create inconsistency between string types and ubyte etc, also that the ability to 'paint' one type as another is desired.
> >>
> >> I think the fact that char, wchar, and dchar have a specified encoding
> >> sets them apart from other types, this fact makes painting one string
> >> type
> >> to another completely useless, I cannot think of a reason to paint a
> >> char[], wchar[] or dchar[] to each other? can you?
> >>
> >> If you can then I suggest something like:
> >>
> >> > #    c = cast(char[]) cast(void[]) d;  // does not call toUTF8()
> >>
> >> will suffice.
> >>
> >> It *does* make sense to paint char[], wchar[] or dchar[] as ubyte[] or void[] etc so what I suggest is that conversion does occur, but, only
if
> >> both the source type and destination type have a specified encoding,
> >> i.e.
> >> char, wchar and dchar to char, wchar or dchar.
> >>
> >> In conclusion I cannot see any valid reason not to make this change, I
> >> believe it makes string handling:
> >>   - simpler
> >>   - more consistent
> >>   - less error prone
> >>
> >> This change would make a string class totally useless, which I believe
> >> was
> >> Walters original intention when creating these types.
> >>
> >> Regan
> >>
> >> --
> >> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> >
> >
>
>
>
> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Tue, 24 Aug 2004 10:44:40 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:
> In article <opsc7jczjt5a2sq9@digitalmars.com>, Regan Heath says...
>
>>>>> Instead, how about a concat(...) method?
>>>
>>> Sure. Let's call it opCat(). And while we're at it, let's give in an
>>> operator to
>>> overload.  :)
>>
>> Don't we already have an opCat? and if not, why not?
>
> Of course we do.
>
> Regan, one thing you should know about my posts is that anything I mark with a
> smiley is something said with a sense of humor. (I know some folk like to put
> <g> at the end of every post, but I don't do that). So if you see a smiley from
> me, it denotes a joke. Similar can be said for any text sandwiched between
> pseudo-tags like <sarcasm>...</sarcasm> or <rant>...</rant>.
>
> I guess I was just hoping you'd see the joke and laugh, but plain text is maybe
> too awkward a medium for that kind of thing.

Duh.. I'm usually pretty good at picking them up. :)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/