roland a écrit :

> i don't know why, but i feel delegate initialisation  can be nicer:

.

> or even if there is only one methode called func:

rectification: as function args are declared with delegate, there is no
ambiguity about witch methode is to be delegated.
so, delegate initialisation could, in theory, always be this format.

> x = delegate(a.func);            //?

roland

"Roland" <rv@ronetech.com> wrote in message news:3CAD5197.5CC2DA84@ronetech.com...
>
> rectification: as function args are declared with delegate, there is no
> ambiguity about witch methode is to be delegated.
> so, delegate initialisation could, in theory, always be this format.
>
> > x = delegate(a.func);            //?
>

Type information (typically) does not flow left-to-right across assignment expressions; in other words, the "delegate" operation can't peek at the "x" across the "=" to find anything out.

But actually, having said that, I already know there's an exception in D. String literals become char literals and wide strings based on their assignment context, so maybe delegates can do similar magic.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a8k6de$5na$1@digitaldaemon.com...
> But actually, having said that, I already know there's an exception in D. String literals become char literals and wide strings based on their assignment context, so maybe delegates can do similar magic.

I had the same thought, but I still haven't figured out what to do in ambiguous cases like:

    void foo(char[]);
    void foo(wchar[]);
    ...
    foo("hello");

Which gets called? Should it be an error?

In any case, I'm leaning towards initializing a delegate with the syntax:

    x = &o.func;

and then using the context to figure out which overloaded func it should be. This does add some complexity to the compiler I don't like.

Walter wrote:
> I had the same thought, but I still haven't figured out what to do in
> ambiguous cases like:
> 
>     void foo(char[]);
>     void foo(wchar[]);
>     ...
>     foo("hello");
> 
> Which gets called? Should it be an error?

Hey, I'm not following the discussion of delegates too
closely, but I've got an opinion on this one.

I'd want a warning on that so as to avoid consequences
of calling the wrong one; since you don't believe in
warnings, it should be an error.

-RB

"Walter" <walter@digitalmars.com> wrote in message news:a8kn36$2hic$1@digitaldaemon.com...

> I had the same thought, but I still haven't figured out what to do in ambiguous cases like:
>
>     void foo(char[]);
>     void foo(wchar[]);
>     ...
>     foo("hello");
>
> Which gets called? Should it be an error?

I guess it shouldn't. The reason is, you will probably define a wchar
version
for each string-handling function, and if it was considered an error, you
wouldn't be able to call those functions with literals as arguments - which
is convenient sometimes.

I'd personally suggest to make some way to differentiate between char and wchar literals (but not that ugly L"..."!).

> In any case, I'm leaning towards initializing a delegate with the syntax:
>
>     x = &o.func;
>
> and then using the context to figure out which overloaded func it should
be.
> This does add some complexity to the compiler I don't like.

Well if function is NOT overloaded (which will most likely be the case), what's the sense of specifying parameters explicitly?

Also, even for overloaded functions, I think the & syntax is better:

    x = &o.func(int, int);

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CADE8E0.1070307@estarcion.com...

> I'd want a warning on that so as to avoid consequences
> of calling the wrong one; since you don't believe in
> warnings, it should be an error.

Imagine:

    class Stream
    {
        void write(char[] s) { ... }
        void write(wchar[] s) { ... }
    }

That's right, two versions, because you might want to feed char[] or wchar[] variable to it. Now, you write:

    stdout.write("Hello, world!");

And get the compiler error, 'cause you must do:

    stdout.write(cast(char[]) "Hello, world!");

You like it?

Pavel Minayev wrote:
> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3CADE8E0.1070307@estarcion.com...
> 
> 
>>I'd want a warning on that so as to avoid consequences
>>of calling the wrong one; since you don't believe in
>>warnings, it should be an error.
>>
> 
> Imagine:
> 
>     class Stream
>     {
>         void write(char[] s) { ... }
>         void write(wchar[] s) { ... }
>     }
> 
> That's right, two versions, because you might want to feed char[]
> or wchar[] variable to it. Now, you write:
> 
>     stdout.write("Hello, world!");
> 
> And get the compiler error, 'cause you must do:
> 
>     stdout.write(cast(char[]) "Hello, world!");
> 
> You like it?

This language design thing is hard. :) Like you, I'd
have to lean towards differentiating char and wchar
literals, or default to char unless there's a \uXXXX
in there somewhere. The latter might give rise to the
(ugly) idiom: "Hello world!\u0000" to force wide char
literal strings.

Sidethread, you complain about the L"literal" syntax
as ugly, but it's far less ugly than the cast.

-R

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CADFE2F.4070502@estarcion.com...

> This language design thing is hard. :) Like you, I'd
> have to lean towards differentiating char and wchar
> literals, or default to char unless there's a \uXXXX
> in there somewhere. The latter might give rise to the
> (ugly) idiom: "Hello world!\u0000" to force wide char
> literal strings.

It isn't proper way since D strings are not 0-terminated, so if you print it, the null char will be printed as well, I guess.

But still the idea is interesting. The compiler should
be able to determine whether string is char or wchar
on his own. Also, if you have function overloaded for both,
then it's not very likely that you have to force wchar
literals, since char version would do exactly the same
(e.g. print the string).

> Sidethread, you complain about the L"literal" syntax
> as ugly, but it's far less ugly than the cast.

Yep, right. But still, L is hard to parse and to distinguish. I think that suffix would be better, "w" or something:

    "Hello, world!"W

Pavel Minayev wrote:
> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3CADFE2F.4070502@estarcion.com...
> 
> 
>>This language design thing is hard. :) Like you, I'd
>>have to lean towards differentiating char and wchar
>>literals, or default to char unless there's a \uXXXX
>>in there somewhere. The latter might give rise to the
>>(ugly) idiom: "Hello world!\u0000" to force wide char
>>literal strings.
>>
> 
> It isn't proper way since D strings are not 0-terminated,
> so if you print it, the null char will be printed as well,
> I guess.

Ohhh, crap. Well, I lobbied for padding (at least char
and wchar) arrays with an extra zero-valued element to
make conversion to C-strings easier way back when, but
noooooooo....

> But still the idea is interesting. The compiler should
> be able to determine whether string is char or wchar
> on his own. Also, if you have function overloaded for both,
> then it's not very likely that you have to force wchar
> literals, since char version would do exactly the same
> (e.g. print the string).

I can contrive cases where the char and wchar versions
do sufficiently different things (e.g. render from a
100KB TrueType font versus render from a 20MB TrueType
font) that the impact would be significant, but even
such cases aren't catastrophic. As you point out, the
numeric promotions and conversions are probably more
troublesome.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CAE8210.4020908@estarcion.com...
> Ohhh, crap. Well, I lobbied for padding (at least char
> and wchar) arrays with an extra zero-valued element to
> make conversion to C-strings easier way back when, but
> noooooooo....

Actually, D does 0 terminate them when it can, for just that reason. But if you slice an array out of another char[], it won't be 0 terminated.