• Matthew Wilson (7/9) Mar 21 2003 literal.
• Walter (5/14) Mar 22 2003 the
• Matthew Wilson (20/36) Mar 22 2003 What are the arguments in favour?
• Walter (8/23) Mar 22 2003 Simplicity.
• Matthew Wilson (4/33) Mar 22 2003 Come on, old bean! I need more than that.
• Vathix (4/4) Mar 31 2003 I think, in that case, it should call the function that takes a char if

"Matthew Wilson" <dmd synesis.com.au> writes:

 Matthew: I'll pursue this myself, but you may recognise something


obvious. It seemed as though a char literal could be passed resolved into
both a char and a char[] parameter.

 Walter: Yes, that is correct. You can force the issue using a cast on the

literal.

Is this something that's been deliberate, and subject to
debate/experimentation? It seems like a bad idea to me, since a instance of
a type is very different from an array of instances of the same (or any
other) type

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b5gt7a$1pf1$1 digitaldaemon.com...
 Matthew: I'll pursue this myself, but you may recognise something


 obvious. It seemed as though a char literal could be passed resolved into
 both a char and a char[] parameter.

 Walter: Yes, that is correct. You can force the issue using a cast on


the
 literal.

 Is this something that's been deliberate, and subject to
 debate/experimentation? It seems like a bad idea to me, since a instance

of
 a type is very different from an array of instances of the same (or any
 other) type

I have some misgivings about it, but I think it needs a chance.

"Matthew Wilson" <dmd synesis.com.au> writes:

What are the arguments in favour?

Against are the obvious confusing one I've said, and the practical one I was
discussing with you in the emails, namely that overloading

char[][] tokenise(char[] string, char[] delimiter, bit bElideBlanks, bit
bNullTerminateSlices);

with

char[][] tokenise(char[] string, char delimiter, bit bElideBlanks, bit
bNullTerminateSlices);

means that in client code I cannot type

  char[][] tokens = tokenise(source, ';', true, false);

without getting a compilation error, which seems preposterous. The overloads
are deliberate because - as you are aware from the offline discussion - I am
aiming for maximal performance, so do not wish to treat a single char as an
array of one element. (And why should I? Isn't D supposed to simplify
programming whilst not reducing programmer's ability for efficiency?)

Please explain.

Matthew



"Walter" <walter digitalmars.com> wrote in message
news:b5i50d$2o49$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b5gt7a$1pf1$1 digitaldaemon.com...
 Matthew: I'll pursue this myself, but you may recognise something


 obvious. It seemed as though a char literal could be passed resolved


into
 both a char and a char[] parameter.

 Walter: Yes, that is correct. You can force the issue using a cast on


 the
 literal.

 Is this something that's been deliberate, and subject to
 debate/experimentation? It seems like a bad idea to me, since a instance

 of
 a type is very different from an array of instances of the same (or any
 other) type

 I have some misgivings about it, but I think it needs a chance.

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:b5ieup$2uqp$1 digitaldaemon.com...
 What are the arguments in favour?

Simplicity.

 Against are the obvious confusing one I've said, and the practical one I

was
 discussing with you in the emails, namely that overloading

 char[][] tokenise(char[] string, char[] delimiter, bit bElideBlanks, bit
 bNullTerminateSlices);

 with

 char[][] tokenise(char[] string, char delimiter, bit bElideBlanks, bit
 bNullTerminateSlices);

 means that in client code I cannot type

   char[][] tokens = tokenise(source, ';', true, false);

 without getting a compilation error, which seems preposterous. The

overloads
 are deliberate because - as you are aware from the offline discussion - I

am
 aiming for maximal performance, so do not wish to treat a single char as

an
 array of one element. (And why should I? Isn't D supposed to simplify
 programming whilst not reducing programmer's ability for efficiency?)

The ambiguity for overloads is a problem. I'll think about it some more.

"Matthew Wilson" <dmd synesis.com.au> writes:

"Walter" <walter digitalmars.com> wrote in message
news:b5ih1d$30ej$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:b5ieup$2uqp$1 digitaldaemon.com...
 What are the arguments in favour?

 Simplicity.

Come on, old bean! I need more than that.

 Against are the obvious confusing one I've said, and the practical one I

 was
 discussing with you in the emails, namely that overloading

 char[][] tokenise(char[] string, char[] delimiter, bit bElideBlanks, bit
 bNullTerminateSlices);

 with

 char[][] tokenise(char[] string, char delimiter, bit bElideBlanks, bit
 bNullTerminateSlices);

 means that in client code I cannot type

   char[][] tokens = tokenise(source, ';', true, false);

 without getting a compilation error, which seems preposterous. The

 overloads
 are deliberate because - as you are aware from the offline discussion -


I
 am
 aiming for maximal performance, so do not wish to treat a single char as

 an
 array of one element. (And why should I? Isn't D supposed to simplify
 programming whilst not reducing programmer's ability for efficiency?)

 The ambiguity for overloads is a problem. I'll think about it some more.

"Vathix" <vathix kernel.net> writes:

I think, in that case, it should call the function that takes a char if
there's one character in the quotes.  Even if it doesn't seem to follow a
pattern, both functions should do the same thing, and char is accessed
faster :)