>> 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

"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.

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.
>
>

"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.

"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.
>
>

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 :)