After the encounter of a conflicting function in std.date
and std.math (floor function), one other conflict seems
to be the toString function in both, std.string and
std.date.

While the floor function in std.date could easily be made private or renamed, the conflicting toString functions in std.date and std.string might be less easy to handle.

My question is - can we expect someday a future D version
where these issues are addressed, or will we always have
to use aliases or type the full path for a range of functions
which share the same name in different library modules?

Bob W wrote:

> After the encounter of a conflicting function in std.date
> and std.math (floor function), one other conflict seems
> to be the toString function in both, std.string and
> std.date.

There's a toString in object.d too, affecting all Objects ?

> My question is - can we expect someday a future D version
> where these issues are addressed, or will we always have
> to use aliases or type the full path for a range of functions
> which share the same name in different library modules?

I wouldn't hold my breath, but it would be a Good Thing...

Even if the D language itself allows functions with the
same name in different modules, one would expect at least
the basic library to be without *too* many such conflicts ?

In the meantime, we get to type out the full function names.


Here's one that I ran into:

> import std.stream;
> import std.stdio;
> 
> void main()
> {
>   stdout.writefln("hello");
> }

variable std.stream.stdout conflicts with std.c.stdio.stdout

Another issue is where you overload:

> void test(char[] str) {}
> void test(wchar[] str) {}
> 
> void main()
> {
>   test("string");
> }

function overload.test overloads void(char[]str) and
void(wchar[]str) both match argument list for test


It just seems that D prefers conflicts to be handled
explicitly, instead of relying on "complicated" rules ?

And of course, Phobos still has a few loose ends left...
(compiling a list of issues, like this one, probably helps)

--anders

On Mon, 21 Feb 2005 13:41:40 +0100, Anders F Björklund <afb@algonet.se> wrote:
> Bob W wrote:
>
>> After the encounter of a conflicting function in std.date
>> and std.math (floor function), one other conflict seems
>> to be the toString function in both, std.string and
>> std.date.

In this case the conflict is caused by a type alias, d_time is aliased to long, meaning the toString(d_time) in std.date has the same signature as the toString(long) in std.string.

Does making the alias a typedef solve it?
I think it _should_, as in if it doesn't isn't it a bug.

> There's a toString in object.d too, affecting all Objects ?

I'm not sure it's the same problem, or any problem at all?

>> My question is - can we expect someday a future D version
>> where these issues are addressed, or will we always have
>> to use aliases or type the full path for a range of functions
>> which share the same name in different library modules?
>
> I wouldn't hold my breath, but it would be a Good Thing...

Ares is supposed to be the communities effort at solidifying and rectifying areas of phobos, this seems like a perfect candidate for change. So, if/when std.date is added to Ares this issue will be addressed.

> Even if the D language itself allows functions with the
> same name in different modules, one would expect at least
> the basic library to be without *too* many such conflicts ?

Agreed. I think in this case the wrong thing "alias" has been used.
Each case is subtlely different.

> In the meantime, we get to type out the full function names.

and/or use aliases.

> Here's one that I ran into:
>
>> import std.stream;
>> import std.stdio;
>>  void main()
>> {
>>   stdout.writefln("hello");
>> }
>
> variable std.stream.stdout conflicts with std.c.stdio.stdout

This one is interesting. I think perhaps one is missnamed.

eg. std.stream.stdout is a File derived from Stream, so it's a stream.
as opposed to std.c.stdio.stdout which is a FILE *

maybe rename std.stream.stdout to std.stream.OutStream or something?

> Another issue is where you overload:
>
>> void test(char[] str) {}
>> void test(wchar[] str) {}
>>  void main()
>> {
>>   test("string");
>> }
>
> function overload.test overloads void(char[]str) and
> void(wchar[]str) both match argument list for test
>
> It just seems that D prefers conflicts to be handled
> explicitly, instead of relying on "complicated" rules ?

In some places. In others it uses implicit casts eg.

void foo(float b) {
    printf("%f\n",b);
}

void main() {
   long a = 5;
   foo(a);
}

compiles, runs, prints "5.000000" :)

> And of course, Phobos still has a few loose ends left...
> (compiling a list of issues, like this one, probably helps)

Definately.

Regan

Anders F Björklund wrote:
[...]
> It just seems that D prefers conflicts to be handled explicitly, instead of relying on "complicated" rules ?
[...]

I would like D to be more symmetric in this field. The comparable opening of scopes by `with'-statments is treated the other way round:

<code>
void main()
{
  int i;
  struct S1{ int i;} S1 s1;
  struct S2{ int i;} S2 s2;
  with( s1) with( s2) i=3;
  printf( "%d %d %d\n", i, s1.i, s2.i);

}
</code>

Here the conflict is resolved by the scope that is opened last. Thereby introducing the possibility of hardly detectable bugs.

-manfred

>> Here's one that I ran into:
>>
>>> import std.stream;
>>> import std.stdio;
>>>  void main()
>>> {
>>>   stdout.writefln("hello");
>>> }
>>
>> variable std.stream.stdout conflicts with std.c.stdio.stdout
>
>This one is interesting. I think perhaps one is missnamed.
>
>eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE *
>
>maybe rename std.stream.stdout to std.stream.OutStream or something?

Personally I'm comfortable with the conflict because someone importing both
std.stream and std.stdio
is asking for two ways to do the same thing so they should have to specify which
"stdout" they mean. In
fact it is cases like this where D's method of dealing with conflicts works
beautifully. We shouldn't
change a desirable name just to avoid a conflict.

On Mon, 21 Feb 2005 22:29:34 +0000 (UTC), Ben Hinkle <Ben_member@pathlink.com> wrote:

>>> Here's one that I ran into:
>>>
>>>> import std.stream;
>>>> import std.stdio;
>>>>  void main()
>>>> {
>>>>   stdout.writefln("hello");
>>>> }
>>>
>>> variable std.stream.stdout conflicts with std.c.stdio.stdout
>>
>> This one is interesting. I think perhaps one is missnamed.
>>
>> eg. std.stream.stdout is a File derived from Stream, so it's a stream.
>> as opposed to std.c.stdio.stdout which is a FILE *
>>
>> maybe rename std.stream.stdout to std.stream.OutStream or something?
>
> Personally I'm comfortable with the conflict because someone importing both
> std.stream and std.stdio
> is asking for two ways to do the same thing so they should have to specify which
> "stdout" they mean.

Sure, but is there a 'better' answer.

> In
> fact it is cases like this where D's method of dealing with conflicts works
> beautifully.

Yeah, but it is 'necessary'.

> We shouldn't
> change a desirable name just to avoid a conflict.

I agree with your statement in general, however:

Is stdout really the 'desirable' name for the output stream?

C++ used cout, perhaps because they couldn't use stdout, perhaps because it's not actually the "standard output" thing.

It seems to me, that it's it's a stream, naming it such tells people what to expect from it.
That said, I personally prefer shorter names where possible, so StandardOutputStream would bug me.

Regan

In article <opsmkl3gpg23k2f5@ally>, Regan Heath says...
>
>On Mon, 21 Feb 2005 22:29:34 +0000 (UTC), Ben Hinkle <Ben_member@pathlink.com> wrote:
>
>>>> Here's one that I ran into:
>>>>
>>>>> import std.stream;
>>>>> import std.stdio;
>>>>>  void main()
>>>>> {
>>>>>   stdout.writefln("hello");
>>>>> }
>>>>
>>>> variable std.stream.stdout conflicts with std.c.stdio.stdout
>>>
>>> This one is interesting. I think perhaps one is missnamed.
>>>
>>> eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE *
>>>
>>> maybe rename std.stream.stdout to std.stream.OutStream or something?
>>
>> Personally I'm comfortable with the conflict because someone importing
>> both
>> std.stream and std.stdio
>> is asking for two ways to do the same thing so they should have to
>> specify which
>> "stdout" they mean.
>
>Sure, but is there a 'better' answer.
>
>> In
>> fact it is cases like this where D's method of dealing with conflicts
>> works
>> beautifully.
>
>Yeah, but it is 'necessary'.
>
>> We shouldn't
>> change a desirable name just to avoid a conflict.
>
>I agree with your statement in general, however:
>
>Is stdout really the 'desirable' name for the output stream?

You're right that if there is a better name we should switch to it. I can't think of a better name, though.

>C++ used cout, perhaps because they couldn't use stdout, perhaps because it's not actually the "standard output" thing.

I was wondering the same thing when I was writing my previous post. I'm curious
what the history was
behind that name. I remember when I first opened up a C++ book and saw "cout" I
thought it stood for
"C output" and wondered why a book about C++ would talk about C's output stream.
:-P
Using that faulty guess of mine we could go with "din" and "dout" - though I'm
sure the joke would be
lost on 99% of the rest of the world.

>It seems to me, that it's it's a stream, naming it such tells people what
>to expect from it.
>That said, I personally prefer shorter names where possible, so
>StandardOutputStream would bug me.

agreed.

>Regan

On Mon, 21 Feb 2005 23:49:25 +0000 (UTC), Ben Hinkle <Ben_member@pathlink.com> wrote:
> In article <opsmkl3gpg23k2f5@ally>, Regan Heath says...
>>
>> On Mon, 21 Feb 2005 22:29:34 +0000 (UTC), Ben Hinkle
>> <Ben_member@pathlink.com> wrote:
>>
>>>>> Here's one that I ran into:
>>>>>
>>>>>> import std.stream;
>>>>>> import std.stdio;
>>>>>>  void main()
>>>>>> {
>>>>>>   stdout.writefln("hello");
>>>>>> }
>>>>>
>>>>> variable std.stream.stdout conflicts with std.c.stdio.stdout
>>>>
>>>> This one is interesting. I think perhaps one is missnamed.
>>>>
>>>> eg. std.stream.stdout is a File derived from Stream, so it's a stream.
>>>> as opposed to std.c.stdio.stdout which is a FILE *
>>>>
>>>> maybe rename std.stream.stdout to std.stream.OutStream or something?
>>>
>>> Personally I'm comfortable with the conflict because someone importing
>>> both
>>> std.stream and std.stdio
>>> is asking for two ways to do the same thing so they should have to
>>> specify which
>>> "stdout" they mean.
>>
>> Sure, but is there a 'better' answer.
>>
>>> In
>>> fact it is cases like this where D's method of dealing with conflicts
>>> works
>>> beautifully.
>>
>> Yeah, but it is 'necessary'.
>>
>>> We shouldn't
>>> change a desirable name just to avoid a conflict.
>>
>> I agree with your statement in general, however:
>>
>> Is stdout really the 'desirable' name for the output stream?
>
> You're right that if there is a better name we should switch to it. I can't
> think of a better name, though.

More thoughts...

Perhaps the new stream is the "standard output", in which case we should rename the old std.c.stdio.stdout to something else.

In a perfect world std.c.stdio.stdout wouldn't be included (unless explicitly) because it's the old C interface which we're trying to leave behind, right?

Can it be changed so that it's privately imported by std.stdio? (I think that's the culprit tho I've not looked in detail)

>> C++ used cout, perhaps because they couldn't use stdout, perhaps because
>> it's not actually the "standard output" thing.
>
> I was wondering the same thing when I was writing my previous post. I'm curious
> what the history was
> behind that name. I remember when I first opened up a C++ book and saw "cout" I
> thought it stood for
> "C output" and wondered why a book about C++ would talk about C's output stream.
> :-P

I thought that exact same thing. Now I wonder... the 'c' can't possibly stand for 'character' can it?

> Using that faulty guess of mine we could go with "din" and "dout" - though I'm
> sure the joke would be
> lost on 99% of the rest of the world.

Those names are definately short...

Regan

>>> C++ used cout, perhaps because they couldn't use stdout, perhaps because it's not actually the "standard output" thing.
>>
>> I was wondering the same thing when I was writing my previous post. I'm
>> curious
>> what the history was
>> behind that name. I remember when I first opened up a C++ book and saw
>> "cout" I
>> thought it stood for
>> "C output" and wondered why a book about C++ would talk about C's output
>> stream.
>> :-P
>
> I thought that exact same thing. Now I wonder... the 'c' can't possibly stand for 'character' can it?

"console" is what I hear the most

On Mon, 21 Feb 2005 21:14:16 -0500, Ben Hinkle <ben.hinkle@gmail.com> wrote:

>>>> C++ used cout, perhaps because they couldn't use stdout, perhaps because
>>>> it's not actually the "standard output" thing.
>>>
>>> I was wondering the same thing when I was writing my previous post. I'm
>>> curious
>>> what the history was
>>> behind that name. I remember when I first opened up a C++ book and saw
>>> "cout" I
>>> thought it stood for
>>> "C output" and wondered why a book about C++ would talk about C's output
>>> stream.
>>> :-P
>>
>> I thought that exact same thing. Now I wonder... the 'c' can't possibly
>> stand for 'character' can it?
>
> "console" is what I hear the most

Duh! of course.

Regan