www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - char[] auto-conversion conflicts with method overloading

reply "antiAlias" <fu bar.com> writes:
There was some commentary about the benefits of auto-conversion between
char[], wchar[] and dchar[], where the compiler will automatically convert
array literals as it sees fit. So, for example, if you have a method:



and call it with:



the compiler will convert the literal to a wchar[] instead of a char[]. This
is apparently considered a GoodThing. Recently, there's been a lot of talk
regarding additional automatic conversion, between UTF8 and its wchar[] and
dchar[] representations.

Unfortunately, all this implicit conversion conflicts badly with method
resolution. For instance, if I have two methods:




the compiler now can't tell which one should be called (vis-a-vis the prior
example). To get around this, one has to cast the string literal like so:




Ugly. What some folks do to get around this is to add different method names
for the same functionality, a la Win32:




They are forced into this approach to avoid having to use those ugly casts
everywhere. This is what Streams.d does, along with others. Okay, so some
might ask why this is a problem? Well, there are certain method names that
are fixed in stone by the compiler, and you can't add a suffix even if you
wanted to:







See the problem? The compiler cannot resolve which constructor to use when
you write



Instead, one is forced to use a cast:



One can hardly add a "W" suffix to the keyword "this". The same thing
happens for operator overloads too. One way around this is to introduce
string prefixes, such as w"this is a wchar string". This has been suggested
before, and it would certainly get rid of those ugly casts (I was under the
misguided impression that casts should not be used on a general basis). BTW:
the w"string" prefix is not a cast; it's a storage-attribute. I'd like to
suggest such prefixes be supported and adopted.

Anyway; the reason for the post is to make folk aware of the kinds of
problems introduced when a compiler performs implicit conversions. This is
bound to become more troublesome if additional "convenience" conversions
occur implicitly within the D language, such as the oft discussed UTF8
conversions.

Please consider.
Sep 03 2004
next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
antiAlias: I for one vote +1 for the addition of a w"" and d"" suffix for
literal strings. (Thanks for pointing out all the issues!)


-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Sep 03 2004
prev sibling next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias <fu bar.com> wrote:

<snip>


 Unfortunately, all this implicit conversion conflicts badly with method
 resolution. For instance, if I have two methods:




 the compiler now can't tell which one should be called (vis-a-vis the 
 prior example).


Why does it matter which method is chosen?
Presumably they both do the same thing?
If not, why not? (Bad design?)

In an event where it does matter (I cannot think of one), then a cast is 
the best way to define the 'right' method if simply because the next guy 
to look at the code will know exactly what you intended.

<snip>

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 05 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <opsdvuwlje5a2sq9 digitalmars.com>, Regan Heath says...

On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias <fu bar.com> wrote:



 Unfortunately, all this implicit conversion conflicts badly with method
 resolution. For instance, if I have two methods:




 the compiler now can't tell which one should be called (vis-a-vis the 
 prior example).


Why does it matter which method is chosen?


i think antiAlias was referring to current behavior, not future possible
behavior. If/when we have implicit run-time conversion between the three D
string types, it won't matter. But right now, we only have implicit compile-time
conversion for string constants, and this conflicts with method resolution.

AntiAlias needs two separate functions because we don't have implicit run-time
conversion. He needs two separate functions because, if the parameters to myFunc
are not compile-time-constants, they won't be implicitly converted.

The fix is, as you say, implicit run-time conversion. Then only one function
would be required. (Though you might want to provide two or even three for
efficiency - hopefully the compiler would be smart enough to call the right
overload if it can avoid a conversion).

Jill
Sep 06 2004
next sibling parent "antiAlias" <fu bar.com> writes:
Unfortunately, it's not quite that simple. When the compiler sees more than
one potentially matching method, it throws an error; implicit conversions
tend to expose more that one match. Perhaps the compiler can be made a bit
smarter in this respect, but there's often subtlety involved ~ keep in mind
that a goal of the D compiler is ease of implementation. It's usually better
to provide a clean mechanism to /support/ the conversion rather than try to
second guess intent. However, using a cast() is not, IMO, the right way.


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:chh2ss$13j6$1 digitaldaemon.com...
In article <opsdvuwlje5a2sq9 digitalmars.com>, Regan Heath says...

On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias <fu bar.com> wrote:



 Unfortunately, all this implicit conversion conflicts badly with method
 resolution. For instance, if I have two methods:




 the compiler now can't tell which one should be called (vis-a-vis the
 prior example).


Why does it matter which method is chosen?


i think antiAlias was referring to current behavior, not future possible
behavior. If/when we have implicit run-time conversion between the three D
string types, it won't matter. But right now, we only have implicit
compile-time
conversion for string constants, and this conflicts with method resolution.

AntiAlias needs two separate functions because we don't have implicit
run-time
conversion. He needs two separate functions because, if the parameters to
myFunc
are not compile-time-constants, they won't be implicitly converted.

The fix is, as you say, implicit run-time conversion. Then only one function
would be required. (Though you might want to provide two or even three for
efficiency - hopefully the compiler would be smart enough to call the right
overload if it can avoid a conversion).

Jill
Sep 06 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 6 Sep 2004 07:16:44 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 In article <opsdvuwlje5a2sq9 digitalmars.com>, Regan Heath says...

 On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias <fu bar.com> wrote:



 Unfortunately, all this implicit conversion conflicts badly with method
 resolution. For instance, if I have two methods:




 the compiler now can't tell which one should be called (vis-a-vis the
 prior example).


 Why does it matter which method is chosen?


 i think antiAlias was referring to current behavior, not future possible
 behavior.


I know. Currently it conflicts, I was suggesting a fix (by asking leading 
questions), it could simply take the first one it finds, as in, if you 
have:

myFunc("hello world");

the constant string has not specific type, so could potentially match any 
of the 3 methods, however, it doesn't matter which method it matches as 
they all (presumably) do the same thing. (*)

If you instead have:

char[] a;
myFunc(a);

then it should match the char[] one, if it cannot find that method it 
should implicitly convert to the one it finds, either wchar[] or dchar[], 
it doesn't matter which it finds as (presumably) they all do the same 
thing. (*)

If a specific method is desired for some reason, then a cast appeals to me 
as the right solution, using it explicitly tells the next programmer to 
look at the code what you intended.

(*) Can anyone think of a potential bug this could cause? to me this 
implicit conversion idea seems identical to the implicit conversion that 
happens between long,int,short etc during method resolution.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 06 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
(*) Can anyone think of a potential bug this could cause? to me this
implicit conversion idea seems identical to the implicit conversion that
happens between long,int,short etc during method resolution.

Yep; you pointed out the issue yourself, Regan (in the "Alias Peek-a-Boo
Game") ~ implicit conversion of primitive types is the reason why all those
wacky inherited-override edge-condition-examples exist, why the method-name
resolution is castrated, and why method aliasing was 'invented' to cover it
all up. That's a band-aid on top of a band-aid, and what you're suggesting
is that the notion be extended to array-content also. I have to agree with
the principal of consistency, but consistently broken is hardly an ideal.

Implicit conversion might look fine & dandy, but its beauty is truly
skin-deep only. It simply does not agree with overloading, particularly
where inheritance is involved.
Sep 06 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 6 Sep 2004 15:52:36 -0700, antiAlias <fu bar.com> wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 (*) Can anyone think of a potential bug this could cause? to me this
 implicit conversion idea seems identical to the implicit conversion that
 happens between long,int,short etc during method resolution.

 Yep; you pointed out the issue yourself, Regan (in the "Alias Peek-a-Boo
 Game") ~ implicit conversion of primitive types is the reason why all 
 those wacky inherited-override edge-condition-examples exist, why the 
 method-name resolution is castrated, and why method aliasing was 
 'invented' to cover it all up. That's a band-aid on top of a band-aid, 
 and what you're suggesting is that the notion be extended to 
 array-content also. I have to agree with the principal of consistency, 
 but consistently broken is hardly an ideal.

 Implicit conversion might look fine & dandy, but its beauty is truly
 skin-deep only. It simply does not agree with overloading, particularly
 where inheritance is involved.


The name resolution rules are identical to those in C/C++ and Walter has 
given reasons for them being that way.

I would personally prefer a perfect solution to the problem, one where 
everyone is happy, given that no-one has voiced one, yet, I am happy with 
the status-quo.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 06 2004
parent reply "antiAlias" <fu bar.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
The name resolution rules are identical to those in C/C++ and Walter has
given reasons for them being that way.

====================

That doesn't mean it's the best way to do it. Or even that it's a /good/
approach. I rather suspect the driving force behind all that was backward
compatibility with existing C implicit conversions (rather than make such
conversion-usage be explicit, for a more strongly-typed language). Note that
D claims to be more strongly-typed ...

Heck; Dennis Ritchie even noted that while C types were influenced heavily
by Algol-68, the designers of the latter would hardly approve of the
type-implementation. I'd wager that he was talking about implicit
conversions <g>

Of course, that doesn't mean D has to follow that same old route, since it
doesn't have to compile raw, poorly written, C code. Nor does it mean we
have to /like/ the current name-resolution implementation :-)

This name-resolution issue is one of the few things about D that feels
flat-out wrong; especially when other modern languages are not bothered by
such arcane nonsense. The one common thing about any design that makes my
skin crawl is the "band-aid". I doubt very much that I'm alone in that
respect.
Sep 06 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 6 Sep 2004 17:37:13 -0700, antiAlias <fu bar.com> wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 The name resolution rules are identical to those in C/C++ and Walter has
 given reasons for them being that way.

 ====================

 That doesn't mean it's the best way to do it. Or even that it's a /good/
 approach.


Of course. I agree. However, I have yet to be presented with an approach 
which I would consider better. I have seen the Java way which suffers from 
a potential hidden bug, which IMO makes it a worse solution than what we 
currently have.


 I rather suspect the driving force behind all that was backward
 compatibility with existing C implicit conversions (rather than make such
 conversion-usage be explicit, for a more strongly-typed language). Note 
 that D claims to be more strongly-typed ...


The whole implicit/explicit problem seems to me to be a line in the sand 
problem, some people want to draw that line in one place, and others in 
another, Walter has drawn the line where he thinks it should be, which is 
the same? or similar? to where C/C++ has it's line.

Implicit conversions give you ease-of-use. Requiring Explicit conversions 
give you robustness, each programmer seems to want a different amount of 
each of those things.


 Heck; Dennis Ritchie even noted that while C types were influenced 
 heavily by Algol-68, the designers of the latter would hardly approve of 
 the
 type-implementation. I'd wager that he was talking about implicit
 conversions <g>


I don't know anything about Algol-68. Is it a strongly typed language? If 
so, you could well be right.


 Of course, that doesn't mean D has to follow that same old route, since 
 it doesn't have to compile raw, poorly written, C code. Nor does it mean 
 we
 have to /like/ the current name-resolution implementation :-)


Each person is entitled to their own opinion, mine is: while I can see the 
problems you (and many others, myself included) have with the current name 
resolution sceme, I cannot think of a better one.


 This name-resolution issue is one of the few things about D that feels
 flat-out wrong;


Is that because you are coming to it from Java? or ..


 especially when other modern languages are not bothered by such arcane 
 nonsense.


I know that Java (which is more modern than C++) uses a different sceme, 
what other 'modern' languages are you referring to, perhaps it would be 
beneficial to investigate a few and attempt to make a list of pros/cons 
for each?


 The one common thing about any design that makes my skin crawl is the 
 "band-aid".


Are you referring to 'alias'?


 I doubt very much that I'm alone in that respect.


No, you're not, quite a few people have expressed dissatisfaction with the 
current system, myself included, however until a 'better' system is 
proposed it will likely remain.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 06 2004
parent reply "antiAlias" <fu bar.com> writes:
"Regan Heath" <regan netwin.co.nz>
Of course. I agree. However, I have yet to be presented with an approach
which I would consider better. I have seen the Java way which suffers from
a potential hidden bug, which IMO makes it a worse solution than what we
currently have.

===================
On whether that is a bug or something else entirely, I will quote yourself:
"IMO this example could be a red herring, engineered to show the bug, not
at all likely in reality"

I fully agree with your statement Regan. The fact that such a (at best)
"questionable" example should mandate this direction is beyond the pale :-)

And what of other, similar, bugs that D doesn't bother to handle? The
required use of 'override' would catch a bunch of rather nasty, and rather
common, ones (unlike that "square" example of a particular engineering
travesty). Yet, 'override' is not required. That kind of argument against
what you call "the Java way" is somewhat futile on several fronts.



 I doubt very much that I'm alone in that respect.


No, you're not, quite a few people have expressed dissatisfaction with the
current system, myself included, however until a 'better' system is
proposed it will likely remain.

=====================
Fair enough. Two notions immediately spring to mind:

1) How does Java successfully combine method-name resolution with implicit
primitive conversion? And what is wrong with adopting that model instead, if
it resolves these problems far more successfully than the existing D
approach does?

2) forget about implicit conversion altogether. Even MSVC v6.0 requires me
to explicitly downcast an int to a char (unless I'm prepared to live with
warnings, which I'm not).

Consider this:

a) isn't it often a sign of inconsistent and potentially buggy design where
an implicit cast is actually generated? In other cases, it's sheer laziness
on the part of the programmer. That's not a criminal offence, but support
for that shouldn't cripple significant aspects of the language either.

b) D will quietly convert a long argument to an int or char parameter
without so much as a peep! This is much looser than MSVC, for crying out
loud ... and should be considered a potential bug, if not an outright one
(and D is supposed to be more typesafe than C?)

c) the implicit conversions of primitive-types makes a total mess of
overload, especially with respect to inheritance. Just look at some of the
bizarre examples given in the past for justifying the current
name-resolution and method-alias scheme <g>

d) implicit conversion also makes a mess of certain operator-overloads, such
that the compiler quits with an error message. The same is true of certain
constructor patterns.

e) method-name alias would not be required, simplifying compiler
implementation and removing a considerable learning impediment from the D
language.

I could go on and on. All this for the sake of the very few explicit
conversions where (a) is not actually a potential bug?

I don't think we're disagreeing here, Regan; other than I'm not satisfied
with the status-quo, whereas you apparently are. The notion of adding
additional implicit-conversion is guaranteed to bring this up again, for
those who care about it.
Sep 06 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <chj8i6$1vt6$1 digitaldaemon.com>, antiAlias says...

1) How does Java successfully combine method-name resolution with implicit
primitive conversion? And what is wrong with adopting that model instead, if
it resolves these problems far more successfully than the existing D
approach does?


Good question.  How does the Java overload resolution scheme work?  And I'm sure
Walter is familiar with it as (IIRC) he's implemented a Java compiler before.


b) D will quietly convert a long argument to an int or char parameter
without so much as a peep! This is much looser than MSVC, for crying out
loud ... and should be considered a potential bug, if not an outright one
(and D is supposed to be more typesafe than C?)


This is incorrect behavior IMO.  Implicit narrowing conversion should not be
allowed.  A messy alternative would be to throw an exception at runtime when an
implicit narrowing conversion results in a loss of data.  All this leaves is how
to handle string and numeric literals, which would either be a cast or a storage
specifier.


Sean
Sep 06 2004
parent reply "antiAlias" <fu bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message

b) D will quietly convert a long argument to an int or char parameter
without so much as a peep! This is much looser than MSVC, for crying out
loud ... and should be considered a potential bug, if not an outright one
(and D is supposed to be more typesafe than C?)


This is incorrect behavior IMO.  Implicit narrowing conversion should not be
allowed.  A messy alternative would be to throw an exception at runtime when
an
implicit narrowing conversion results in a loss of data.  All this leaves is
how
to handle string and numeric literals, which would either be a cast or a
storage
specifier.

Sean

======================

Better, I assert, to produce a compile-time error ~ requiring an explicit
conversion to remedy the situation (such as the cast or storage-specifier
you speak of). Of course, that's only for those cases where the compiler
didn't actually just show you a bug. Sure makes compiler implementation
easier too :-)
Sep 06 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 6 Sep 2004 20:36:53 -0700, antiAlias <fu bar.com> wrote:

 "Sean Kelly" <sean f4.ca> wrote in message

 b) D will quietly convert a long argument to an int or char parameter
 without so much as a peep! This is much looser than MSVC, for crying out
 loud ... and should be considered a potential bug, if not an outright 
 one
 (and D is supposed to be more typesafe than C?)


 This is incorrect behavior IMO.  Implicit narrowing conversion should 
 not be
 allowed.  A messy alternative would be to throw an exception at runtime 
 when
 an
 implicit narrowing conversion results in a loss of data.  All this 
 leaves is
 how
 to handle string and numeric literals, which would either be a cast or a
 storage
 specifier.

 Sean

 ======================

 Better, I assert, to produce a compile-time error ~ requiring an explicit
 conversion to remedy the situation (such as the cast or storage-specifier
 you speak of). Of course, that's only for those cases where the compiler
 didn't actually just show you a bug. Sure makes compiler implementation
 easier too :-)


I agree. Narrowing conversions should have to explicit IMO.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 06 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <opsdxyhltt5a2sq9 digitalmars.com>, Regan Heath says...


I agree. Narrowing conversions should have to explicit IMO.


Absolutely I agree 100%.

Of course, string conversions are not narrowing, in /any/ direction. Whether you
go from char[] to dchar[], dchar[] to char[], or any other combination, the
conversion yields zero loss of information, and so should be considered neither
widening nor narrowing. String conversions (between the UTFs) are always
lossless.

Arcane Jill
Sep 07 2004
prev sibling next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 6 Sep 2004 20:08:41 -0700, antiAlias <fu bar.com> wrote:

 "Regan Heath" <regan netwin.co.nz>
 Of course. I agree. However, I have yet to be presented with an approach
 which I would consider better. I have seen the Java way which suffers 
 from
 a potential hidden bug, which IMO makes it a worse solution than what we
 currently have.

 ===================
 On whether that is a bug or something else entirely, I will quote 
 yourself:
 "IMO this example could be a red herring, engineered to show the bug, not
 at all likely in reality"

 I fully agree with your statement Regan. The fact that such a (at best)
 "questionable" example should mandate this direction is beyond the pale 
 :-)


The statement above was only saying it 'could' be a red herring, I was not 
convinced either way at the time of writing it.

The example given _was_ engineered to show the bug, but then, of course it 
was, how else would Walter get an example.

For those interested here are the examples given at the time...

<Walter>
Stroustrup gives two examples (slightly modified here):

---------------------------------
class X1 { void f(int); }

  // chain of derivations X(n) : X(n-1)

class X9: X8 { void f(double); }

void g(X9 p)
{
     p.f(1);    // X1.f or X9.f ?
}
-----------------------------------
His argument is that one can easilly miss an overload of f() somewhere in a
complex class heirarchy, and argues that one should not need to understand
everything about a class heirarchy in order to derive from it. The other
example involves operator=(), but since D doesn't allow overloading
operator=() instead I'll rewrite it as if it were a function that needs to
alter a class state, and a derived class written later that 'caches' a
computation on the derived state:

class B
{    long x;
      void set(long i) { x = i; }
     void set(int i) { x = i; }
     long squareIt() { return x * x; }
}
class D : B
{
     long square;
     void set(long i) { B.set(i); square = x * x; }
     long squareIt() { return square; }
}

Now, imagine B were a complex class with a lot of stuff in it, and our
optimizing programmer missed the existence of set(int). Then, one has:

     long foo(B b)
     {
         b.set(3);
         return b.squareIt();
     }

and we have an obscure bug.
</Walter>



 And what of other, similar, bugs that D doesn't bother to handle? The
 required use of 'override' would catch a bunch of rather nasty, and 
 rather
 common, ones


I agree, I am a proponent (sp?) for the required use of the override 
keyword.



 (unlike that "square" example of a particular engineering
 travesty). Yet, 'override' is not required. That kind of argument against
 what you call "the Java way" is somewhat futile on several fronts.


I am only calling it "the Java way" because Java is the only language I 
know of to do name resolution in the manner you want.




 I doubt very much that I'm alone in that respect.


 No, you're not, quite a few people have expressed dissatisfaction with 
 the
 current system, myself included, however until a 'better' system is
 proposed it will likely remain.

 =====================
 Fair enough. Two notions immediately spring to mind:

 1) How does Java successfully combine method-name resolution with 
 implicit primitive conversion?


It doesn't, "Roberto Mariottini" tried Walters example above in Java, he 
found..

<Roberto Mariottini>
I translated your example in Java, and it shows the "wrong" (non-C++) 
behaviour.
The attached Test.java prints:

The square is: 0
</Roberto Mariottini>



 And what is wrong with adopting that model instead, if it resolves these 
 problems far more successfully than the existing D
 approach does?


IMO it doesn't resolve them 'more sucessfully', that is what is wrong with 
adopting it.




 2) forget about implicit conversion altogether. Even MSVC v6.0 requires 
 me to explicitly downcast an int to a char (unless I'm prepared to live 
 with
 warnings, which I'm not).


What you describe above int -> char is a narrowing conversion, I agree, a 
narrowing conversion should have to be explicit.




 Consider this:

 a) isn't it often a sign of inconsistent and potentially buggy design 
 where an implicit cast is actually generated? In other cases, it's sheer 
 laziness on the part of the programmer. That's not a criminal offence, 
 but support
 for that shouldn't cripple significant aspects of the language either.


I wouldn't call it 'sheer laziness' I would call it 'convenience' and as I 
said earlier, each programmer desires a different balance between 
convenience and robustness.




 b) D will quietly convert a long argument to an int or char parameter
 without so much as a peep! This is much looser than MSVC, for crying out
 loud ... and should be considered a potential bug, if not an outright one
 (and D is supposed to be more typesafe than C?)


I agree, if D does that narrowing conversion (it seems to in my tests) 
then it is bad. This may be a case where Walter has drawn the line too far 
on the side of convenience.




 c) the implicit conversions of primitive-types makes a total mess of
 overload, especially with respect to inheritance. Just look at some of 
 the bizarre examples given in the past for justifying the current
 name-resolution and method-alias scheme <g>

 d) implicit conversion also makes a mess of certain operator-overloads, 
 such that the compiler quits with an error message. The same is true of 
 certain constructor patterns.


I need examples for the 2 above, my memory isn't good enough to remember 
them, or what to search for to find them.



 e) method-name alias would not be required, simplifying compiler
 implementation and removing a considerable learning impediment from the D
 language.


The 'alias' keyword is used to explicitly import symbols into the current 
scope.. I thought you were all for explicit <g>

So, on one hand you don't want implicit type conversion, as it introduces 
bugs... but on the other you do want implicit inclusion of symbols in the 
child class scope... and this also introduces bugs... but you're happy 
with one set of bugs and not the other?



 I could go on and on. All this for the sake of the very few explicit
 conversions where (a) is not actually a potential bug?



 I don't think we're disagreeing here, Regan; other than I'm not satisfied
 with the status-quo, whereas you apparently are.


Well..  I'm not satisfied with it, but, it's the best I've seen so far.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 06 2004
parent reply "antiAlias" <fu bar.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message

 a) isn't it often a sign of inconsistent and potentially buggy design
 where an implicit cast is actually generated? In other cases, it's sheer
 laziness on the part of the programmer. That's not a criminal offence,
 but support
 for that shouldn't cripple significant aspects of the language either.


I wouldn't call it 'sheer laziness' I would call it 'convenience' and as I
said earlier, each programmer desires a different balance between
convenience and robustness.

========
You'd happily trade-off robustness for a few keystrokes? If you're serious,
then Matthew's choice-phrase for that sort of attitude towards design &
coding fits the bill quite nicely. I think you should start another topic on
that one :-)

That aside, you avoided the point.




 e) method-name alias would not be required, simplifying compiler
 implementation and removing a considerable learning impediment from the D
 language.


So, on one hand you don't want implicit type conversion, as it introduces
bugs... but on the other you do want implicit inclusion of symbols in the
child class scope... and this also introduces bugs... but you're happy
with one set of bugs and not the other?

===============
I'm truly surprised, Regan. You seemed to understand the issue, and then say
this?
Sep 06 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 6 Sep 2004 22:57:44 -0700, antiAlias <fu bar.com> wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message

 a) isn't it often a sign of inconsistent and potentially buggy design
 where an implicit cast is actually generated? In other cases, it's sheer
 laziness on the part of the programmer. That's not a criminal offence,
 but support
 for that shouldn't cripple significant aspects of the language either.


 I wouldn't call it 'sheer laziness' I would call it 'convenience' and as 
 I
 said earlier, each programmer desires a different balance between
 convenience and robustness.

 ========
 You'd happily trade-off robustness for a few keystrokes?


Yes. IMO:

-- 'few' is incorrect, try millions.
-- the robustness I actually loose is miniscule.

obviously you will disagree with both of the above. That was my other 
point: each person wants to draw the line in a different place. You favour 
robustness over convenience, I prefer a little more convenience and (given 
the narrowing implicit conversions in D) Walter wants even more convience 
(or they're a bug).


 If you're serious,then Matthew's choice-phrase for that sort of attitude 
 towards design &
 coding fits the bill quite nicely. I think you should start another 
 topic on that one :-)
 That aside, you avoided the point.


Which one?

a. an implicit cast is a sign of bad design?
b. an implicit cast is a sign of a lazy programmer?
c. implicit conversions cripple the language?

Those are all I see above, so, my responses..

a & b) If you have implicit casts (which we do) then we will use them, 
it's only the un-intentional use of them which could be hazardous, and 
generally it's only a problem if it's a narrowing conversion, which IMO 
should never be implicit.

c) is C/C++ crippled? It doesn't seem to be.


 e) method-name alias would not be required, simplifying compiler
 implementation and removing a considerable learning impediment from the 
 D language.


 So, on one hand you don't want implicit type conversion, as it introduces
 bugs... but on the other you do want implicit inclusion of symbols in the
 child class scope... and this also introduces bugs... but you're happy
 with one set of bugs and not the other?

 ===============
 I'm truly surprised, Regan. You seemed to understand the issue, and then 
 say this?


Are you gonna tell me what you dislike about it, or leave me guessing?

Basically what I am trying to point out is:

-- what you want is for symbols to be included 'implicitly'.
-- what you dont want is for types to be converted 'implicitly'.

IMO anything done implicitly creates a chance that it was not what the 
programmer intended and thus can cause bugs, we have had examples of them 
for both of the above.

What I don't understand is how you can desire robustness *and* implicit 
symbol inclusion (which has been shown to decrease robustness)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 07 2004
parent reply "antiAlias" <fu bar.com> writes:
This little excursion started out as a mere heads' up regarding some issues
with respect to implicit conversion. That post ended with the request to
"Please consider", before further implicit conversion might be added to the
compiler.

I won't pretend to understand the reasons why this topic has been dragged
through the gutter. Perhaps there's a need to divert attention, from the
original point? Perhaps there's some other unseen notion at play. Whatever
the goal, posting here is becoming an increasingly futile exercise. That's a
shame.

I'll make this one response to your ever-escalating drivel, Regan, and then
bid you adieu:

******************************

| IMO anything done implicitly creates a chance that it was not what the
| programmer intended and thus can cause bugs, we have had examples of them

Now you've completely flip-flopped, and are making my point for me. Doh!
That's okay though.


| > So, on one hand you don't want implicit type conversion, as it
introduces
| > bugs... but on the other you do want implicit inclusion of symbols in
the
| > child class scope... and this also introduces bugs... but you're happy
| > with one set of bugs and not the other?
| >
| -- what you want is for symbols to be included 'implicitly'.
| -- what you dont want is for types to be converted 'implicitly'.
|
| What I don't understand is how you can desire robustness *and* implicit
| symbol inclusion (which has been shown to decrease robustness)


Au Contraire;

First; you're hanging onto half-baked notions of what you term implicit and
explicit. Second; you continue to cast what, you appear to hope, are vaguely
contradictory notions my way, with no substance whatsoever to back them up.

Let's take a look at those shall we?

You claim that inheritance of methods is implicit. Or, rather you claim that
I do, and use that as a basis for derogatory remark. I've got news for you
Regan: inheritance is /explicit/. You appear to conveniently forget that
little detail. When you inherit, you must do so explicitly, like so:

class X : Y {}

What this does, Regan, is to extend class X with all the functionality that
class Y exposes (or vice versa, if you prefer). You, as a programmer, have
taken an explicit action to make this happen, and are telling the compiler
that you are assuming responsibility for the consequence of your action.

You've pointed out in the past that you've not used C++ before, nor Java, so
one might understand your confusion over this basic point. However, you
should perhaps consider this lack of experience before rifling others over
such matters. After all, it was only recently that you learned the
distinction between override and overload:
news:opsbtjg6ko5a2sq9 digitalmars.com Your claimed 6 year of writing C does
not do you any favours in such matters. While we're on that subject; you
talk about a "child class" instead of superclass (they are quite different
things), and you talk about "symbols" instead of inherited methods. Please
try to be a little more accurate with terminology, as it will assist you.

If we assume that you already know inheritance is an explicit action, then
your rhetoric becomes clear for what it is; all inherited methods
(non-private) are indeed included into the scope of a derived class
/by default/. That is the way method inheritance operates, Regan. D (and
C++) have a number of special cases in this respect; one of which is with
regard to methods of the same name. It's been shown on a number of prior
occasions where such special cases can lead. Here's one that would have been
rather amusing, were it not for the consequence:
news:cgat6b$1424$1 digitaldaemon.com


As for your deluded assertion that I have some contrary notion in mind;
consider this: news:ce44ka$1ji4$1 digitaldaemon.com

Perhaps that will put paid to your snide and bizarre aberrations? I think
perhaps you should read more, Regan. Without getting your facts straight,
you tend to look a bit foolish.


| > You'd happily trade-off robustness for a few keystrokes?
|
| Yes. IMO:

Then you do not deserve that job of yours in tech-support, or product
development, or whatever it is you claim to do. Trading off
software-robustness is perhaps questionable at any level, but trading it off
for laziness is shallow in the extreme. You're advocating more of that
should be built into the compiler. Thankfully, you then go on to contradict
yourself again with this:

| IMO anything done implicitly creates a chance that it was not what the
| programmer intended and thus can cause bugs, we have had examples of them


Hallelujah!


Lastly: You have a big mouth, Regan. Perhaps you should put your money where
that mouth is, and post an extensive essay upon the detrimental aspects of
what you term "the Java way" regarding this topic, and compare/contrast with
all the documented "quirks" of the D approach?  Please try to form some
semblance of punctuation while you're at it. And don't forget to try and get
the terminology straight.

Others have been willing to do so in the past, and face the consequences. I
should imagine that you'd prefer to stay behind your little desk instead;
brazenly decrying alternate approaches to the discussed issues without
understanding them in the first place. Put up the money, Regan. If you do
so, then you might even get some of the respect you seem to need so
desperately.

Have a nice life, dude. And thanks for the entertainment!
Sep 08 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 8 Sep 2004 10:24:50 -0700, antiAlias <fu bar.com> wrote:

 This little excursion started out as a mere heads' up regarding some 
 issues
 with respect to implicit conversion. That post ended with the request to
 "Please consider", before further implicit conversion might be added to 
 the
 compiler.

 I won't pretend to understand the reasons why this topic has been dragged
 through the gutter. Perhaps there's a need to divert attention, from the
 original point? Perhaps there's some other unseen notion at play. 
 Whatever
 the goal, posting here is becoming an increasingly futile exercise. 
 That's a
 shame.

 I'll make this one response to your ever-escalating drivel, Regan, and 
 then
 bid you adieu:


Kris, we're all adults here (at least I thought we were), your habit of 
abusing someone because they disagree with you is childish at best. If you 
cannot handle having your opinions disagreed with I suggest you stop 
posting them.

I was tempted to leave this reply at that, but for the sake of continued 
understanding I will attempt to clear up our recent missunderstandings...




 ******************************

 | IMO anything done implicitly creates a chance that it was not what the
 | programmer intended and thus can cause bugs, we have had examples of 
 them

 Now you've completely flip-flopped,


No, I have not.



 and are making my point for me. Doh!
 That's okay though.


Im not sure to which point you are referring?

I am perfectly willing to accept implicit behaviour can cause unexpected 
results. I am perfectly willing to accept that requiring explicit 
behaviour creates more robust code.

The points I am trying to make (which you seem to miss) are:

- that each person desires a different balance between the two.
- that the behaviour you have been asking for is implicit behaviour.



 | > So, on one hand you don't want implicit type conversion, as it
 introduces
 | > bugs... but on the other you do want implicit inclusion of symbols in
 the
 | > child class scope... and this also introduces bugs... but you're 
 happy
 | > with one set of bugs and not the other?
 | >
 | -- what you want is for symbols to be included 'implicitly'.
 | -- what you dont want is for types to be converted 'implicitly'.
 |
 | What I don't understand is how you can desire robustness *and* implicit
 | symbol inclusion (which has been shown to decrease robustness)


 Au Contraire;

 First; you're hanging onto half-baked notions of what you term implicit 
 and
 explicit. Second; you continue to cast what, you appear to hope, are 
 vaguely
 contradictory notions my way, with no substance whatsoever to back them 
 up.

 Let's take a look at those shall we?

 You claim that inheritance of methods is implicit.


No, I did not.


 Or, rather you claim that
 I do


No, I did not.


 , and use that as a basis for derogatory remark.


No, I did not.

You seem to continually misunderstand, misconstrue and misrepresent my 
comments.

I am perfectly aware what implicit and explicit mean, you seem to have 
missunderstood what I was referring to. Perhaps I was not clear enough, 
perhaps I should have explicitly used the word overloaded when referring 
to inheritance, I hope it's clearer now.



 I've got news for you
 Regan: inheritance is /explicit/. You appear to conveniently forget that
 little detail. When you inherit, you must do so explicitly, like so:

 class X : Y {}

 What this does, Regan, is to extend class X with all the functionality 
 that
 class Y exposes (or vice versa, if you prefer). You, as a programmer, 
 have
 taken an explicit action to make this happen, and are telling the 
 compiler
 that you are assuming responsibility for the consequence of your action.


Yes, I realise inheritance is explicit, however inheritance itself is not 
the problem you're having. The problem you're having is with "overloaded" 
inherited methods and name resolution.

What you want is for overloaded inherited methods to be implicitly 
included in the child class scope for name resolution. (Correct me if I am 
wrong).

This behaviour is *not* currently the case, and you must explicitly 
'alias' them in.



 You've pointed out in the past that you've not used C++ before, nor 
 Java, so
 one might understand your confusion over this basic point. However, you
 should perhaps consider this lack of experience before rifling others 
 over
 such matters.


Yet again you seem to simply be taking exception to me disagreeing with 
you. I have no idea what "rifling others" is, but I am pretty sure I have 
done no such thing.

Unless I am mistaken this is a 'News Group' where people come to share 
their knowledge and opinions on various things, where people discuss those 
opinions and form new ones. If you cannot handle me or anyone else doing 
that, then I suggest you leave.

All I have ever been trying to do is share my opinion.



 After all, it was only recently that you learned the
 distinction between override and overload:


To be perfectly honest, I understood the concept just not the correct term 
to use.



 news:opsbtjg6ko5a2sq9 digitalmars.com Your claimed 6 year of writing C 
 does
 not do you any favours in such matters. While we're on that subject; you
 talk about a "child class" instead of superclass (they are quite 
 different
 things), and you talk about "symbols" instead of inherited methods. 
 Please
 try to be a little more accurate with terminology, as it will assist you.


Thank you, it was simply the terminology that I lack, I am catching up 
however.



 If we assume that you already know inheritance is an explicit action, 
 then
 your rhetoric becomes clear for what it is; all inherited methods
 (non-private) are indeed included into the scope of a derived class
 /by default/. That is the way method inheritance operates, Regan. D (and
 C++) have a number of special cases in this respect; one of which is with
 regard to methods of the same name. It's been shown on a number of prior
 occasions where such special cases can lead. Here's one that would have 
 been
 rather amusing, were it not for the consequence:
 news:cgat6b$1424$1 digitaldaemon.com


You're right, inherited methods are included, however, they're not the 
problem here. The problem is with "overloaded" inherited methods, which 
are not included and must be explicitly aliased in.

<snip>

I have snip'ped the last part of this post because you seem to have 
degenerated into name calling, something I won't join you in doing.


To all the other people taking part in this NG:

If I am offending anyone in any way, shape or form with any 
comments/arguments/opinions I have voiced please let me know, either post 
here, or email me directly (the above address is valid)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 08 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
 To all the other people taking part in this NG:

 If I am offending anyone in any way, shape or form with any
comments/arguments/opinions I have voiced please let me 
 know, either post here, or email me directly (the above address is valid)


I won't single anyone out - though I'll take my share of the blame - but this
NG has degenerated enormously in the last 
few months to the point of unreadability. (I've now all but stopped reading it,
but was prompted to digest this thread 
at the behest of a friend, who wanted my opinion.)

I think this has happened due to two factors:

1. The increasing visibility of D has brought a lot of new people in, many of
whom appear to prefer to yack than hack. 
(As is their right, of course.)
2. The increasing frustrations of the extant D community
    (i) to the degrading yack:hack ratio, and, probably more significantly,
    (ii) with the evolution of the language and its libraries. As the language
ages, more things are found to be 
fundamentally wrong with it, and yet fewer things *appear* (I may be wrong, so
I'll stick with appear) to be addressed. 
There are a disconcerting number of warts in D already, and yet many people
were drawn to it because of its promise to 
be evolutionary and learning from the mistakes of other languages. Again
(caveats to the fore), I may be wrong here, but 
it sure feels like this is the case. I don't doubt that, if anyone was
motivated, we could easily amass a list of 20-30 
serious show-stopping (or, rather, sideline-precipitating) warts in the
language itself. But it seems like there's very 
little interest in these "higher" issues, especially where Walter disagrees
with them - <too many to list> - or deems 
them unimportant - e.g. the opApply() delegate return type.

Of all my competent non-D friends - i.e. people who have many years experience
in several systems and scripting 
languages - none whom I managed to persuade to look at it seriously over the
last couple of years have been motivated to 
stick with it, and I've been unable to motivate a single one to even look at it
in, say, the last 6 months. This is not 
promising.

For my part, I am still keen to see D succeed, and I still believe it _can_,
but I am less sure that it _will_ than I 
used to be. It has some very powerful advantages over other languages, but I
fear they're likely to be deemed 
insignificant when basic issues of usability, large-scale development and
robustness remain unaddressed.

:-(

Matthew
Sep 08 2004
parent reply pragma <pragma_member pathlink.com> writes:
In article <chop6a$1n94$1 digitaldaemon.com>, Matthew says...

[...] this NG has degenerated enormously in the last 
few months to the point of unreadability. [...]

I think this has happened due to two factors:

1. The increasing visibility of D has brought a lot of new people in, many of
whom appear to prefer to yack than hack. 


I, for one, agree.  It's a symptom of the movement that D has created.  From the
beginning I was apprehensive how this group would behave as participation grew.
I think the NG is beginning to mature and is soon going to be in need of a basic
NG-FAQ to help keep the noobs with the basics.  Thankfully, the group has been
fairly well self-moderated which is evident by how quickly some problems are
dealt with.

As a side note, I don't see the amount of chatter on the group a problem so long
as its positive.  After all, how the heck are we supposed to get along or agree
on anything without knowing at least a little bit about each others goals and
interests?  Also, the amount of messageboard volume over on dsource has shown
that a good amount of D-based discussion, that could have been dumped here, is
instead being focused on a project-by-project basis; and more is moving there
all the time, like with Ares (PhobosRising).  Could the amount of yacking here
be the result of this trend?


(As is their right, of course.)
2. The increasing frustrations of the extant D community
    (i) to the degrading yack:hack ratio, and, probably more significantly,
    (ii) with the evolution of the language and its libraries. As the language
ages, more things are found to be 
fundamentally wrong with it, and yet fewer things *appear* (I may be wrong, so
I'll stick with appear) to be addressed. 
There are a disconcerting number of warts in D already, and yet many people
were drawn to it because of its promise to 
be evolutionary and learning from the mistakes of other languages. Again
(caveats to the fore), I may be wrong here, but 
it sure feels like this is the case. I don't doubt that, if anyone was
motivated, we could easily amass a list of 20-30 
serious show-stopping (or, rather, sideline-precipitating) warts in the
language itself. But it seems like there's very 
little interest in these "higher" issues, especially where Walter disagrees
with them - <too many to list> - or deems 
them unimportant - e.g. the opApply() delegate return type.


Again, I agree.  It may look like development is being stalled, but I think that
may be due to forces well beyond Walter's control.  Then again, who else other
than he is able to speak for these points directly?  

When Ares lifts off, I can see the language library issues being addressed at
least in parallel with the core distribution.  I feel bad advocating that we (as
a community of developers) circumvent the core development of the language, but
I really don't see any other way to accomplish rapid progress.

As for the compiler and language issues, perhaps some of us (I'm not implying
Matthew BTW, but honestly anyone who's read this far) may take to deeper hacking
of the dmd frontend to determine how and why certain things break?  If it helps,
I know that the closer one gets to solving the problem directly, when filing a
bug report, the more attention it recieves.


Of all my competent non-D friends - i.e. people who have many years experience
in several systems and scripting 
languages - none whom I managed to persuade to look at it seriously over the
last couple of years have been motivated to 
stick with it, and I've been unable to motivate a single one to even look at it
in, say, the last 6 months. This is not 
promising.


Yep, some of the shouting and trolling here in the group certainly doesn't help
the overall image of Walter's (or anyone else's) efforts, especially since this
is one of the only places where one can go to keep current on D.  One only has
to look at the blog site for Mono to see how even a modest improvement in
maturity can impact the presence of a technology (even if its nothing new).  But
then again, mono's blog is developers *only* so there's something to be said for
selecting your representatives to the world at large.

I'm not at all suprised that its been difficult to get others interested.  I've
run into the same problem, but only because I have nothing to say that will
really "hook" someone.  The most compact thing I can say about D that does it
any justice is: "A compiled, portable, object-oriented, garbage-collected C
dialect that out performs similar technologies."  Anyone who understands that
mouthful of jargon gets it, but is then soundly dissapointed by its beta status.


Here's the way I see it: D has innumerable /slight/ advantages over similar
languages.  There is no single "killer feature" that will really entice a hoard
of people in.  So we must get the word out that "D is an all round better
language" than others.  This will take nothing short of the community here
putting its best foot forward to entice new and old developers alike.  It means
better promotion and more complete projects.  Something high profile would be a
boon too.

Also, once we clear V1.0, I expect many to take D more seriously.  In the
meantime, D is stable enough now to accomplish a world of good.

- Pragma
[[ Eric Anderton at (d is good) yahoo dot com]]
Sep 09 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"pragma" <pragma_member pathlink.com> wrote in message
news:chq1ak$2e62$1 digitaldaemon.com...

 In article <chop6a$1n94$1 digitaldaemon.com>, Matthew says...

[...] this NG has degenerated enormously in the last
few months to the point of unreadability. [...]

I think this has happened due to two factors:

1. The increasing visibility of D has brought a lot of new people in, many of
whom appear to prefer to yack than hack.


 I, for one, agree.  It's a symptom of the movement that D has created.  From
the
 beginning I was apprehensive how this group would behave as participation grew.
 I think the NG is beginning to mature and is soon going to be in need of a
basic
 NG-FAQ to help keep the noobs with the basics.  Thankfully, the group has been
 fairly well self-moderated which is evident by how quickly some problems are
 dealt with.

 As a side note, I don't see the amount of chatter on the group a problem so
long
 as its positive.  After all, how the heck are we supposed to get along or agree
 on anything without knowing at least a little bit about each others goals and
 interests?


12-18 months ago, there was a happy community and people did indeed exchange
personal/OT debates, and no-one minded.
Indeed, it helped cement relationships and provided some nice entertainment.
People at that time were earnest, but there
was little of the dogma and ego that haunts it now. It may well be that this in
an inevitable part of any movement as it
expands, but I don't think that's entirely covers it.


  Also, the amount of messageboard volume over on dsource has shown
 that a good amount of D-based discussion, that could have been dumped here, is
 instead being focused on a project-by-project basis; and more is moving there
 all the time, like with Ares (PhobosRising).  Could the amount of yacking here
 be the result of this trend?


(As is their right, of course.)
2. The increasing frustrations of the extant D community
    (i) to the degrading yack:hack ratio, and, probably more significantly,
    (ii) with the evolution of the language and its libraries. As the language
ages, more things are found to be
fundamentally wrong with it, and yet fewer things *appear* (I may be wrong, so
I'll stick with appear) to be
addressed.
There are a disconcerting number of warts in D already, and yet many people
were drawn to it because of its promise to
be evolutionary and learning from the mistakes of other languages. Again
(caveats to the fore), I may be wrong here,
but
it sure feels like this is the case. I don't doubt that, if anyone was
motivated, we could easily amass a list of
20-30
serious show-stopping (or, rather, sideline-precipitating) warts in the
language itself. But it seems like there's
very
little interest in these "higher" issues, especially where Walter disagrees
with them - <too many to list> - or deems
them unimportant - e.g. the opApply() delegate return type.


 Again, I agree.  It may look like development is being stalled, but I think
that
 may be due to forces well beyond Walter's control.  Then again, who else other
 than he is able to speak for these points directly?


Exactly the point!


 When Ares lifts off, I can see the language library issues being addressed at
 least in parallel with the core distribution.  I feel bad advocating that we
(as
 a community of developers) circumvent the core development of the language, but
 I really don't see any other way to accomplish rapid progress.


I've gone off the idea. I'm now tending towards thinking that we need
Walter/Phobos action on issues, one at a time. I'd
like to see a Library Issue Of The Week, *including* Walter's
attention/involvement. For example, I'd suggest that we
clean up the Exception/Error Hierarchy this week. Why not?

[Since I wrote the first part of this response, Walter's agreed to this very
notion, so now I have to eat my own words,
and dance to the manic ditty I've been singing. :-)]


 As for the compiler and language issues, perhaps some of us (I'm not implying
 Matthew BTW, but honestly anyone who's read this far) may take to deeper
hacking
 of the dmd frontend to determine how and why certain things break?  If it
helps,
 I know that the closer one gets to solving the problem directly, when filing a
 bug report, the more attention it recieves.


Would love to, but have not the time, and cannot imagine ever getting it, alas.


Of all my competent non-D friends - i.e. people who have many years experience
in several systems and scripting
languages - none whom I managed to persuade to look at it seriously over the
last couple of years have been motivated
to
stick with it, and I've been unable to motivate a single one to even look at it
in, say, the last 6 months. This is
not
promising.


 Yep, some of the shouting and trolling here in the group certainly doesn't help
 the overall image of Walter's (or anyone else's) efforts, especially since this
 is one of the only places where one can go to keep current on D.  One only has
 to look at the blog site for Mono to see how even a modest improvement in
 maturity can impact the presence of a technology (even if its nothing new). 
But
 then again, mono's blog is developers *only* so there's something to be said
for
 selecting your representatives to the world at large.


I shall have a look.


 I'm not at all suprised that its been difficult to get others interested.  I've
 run into the same problem, but only because I have nothing to say that will
 really "hook" someone.  The most compact thing I can say about D that does it
 any justice is: "A compiled, portable, object-oriented, garbage-collected C
 dialect that out performs similar technologies."  Anyone who understands that
 mouthful of jargon gets it, but is then soundly dissapointed by its beta
status.


There are some *really* challenging issues ahead, most notably getting DLLs and
GC to work in large-scale/project
scenarios. Until such issues are resolved, D's only going to be good for
implementing stand-alone link-units, or those
that cooperate via C-APIs. (Not that I am troubled by such things, since that's
the only way I use C++, but it's too
much boilerplate and nitty-gritty for a new language to require of its users.)


 Here's the way I see it: D has innumerable /slight/ advantages over similar
 languages.  There is no single "killer feature" that will really entice a hoard
 of people in.


Not sure I agree. I think D's combination of some borrowed features makes it
unique. (I'm not saying any more, as I'm 
trying to get an article up for DDJ on this very point ... <g>)


  So we must get the word out that "D is an all round better
 language" than others.


Is it? I didn't think such a thing existed. For example, I recently changed the
license information in *all* of the 
STLSoft and recls libraries, and a whole lot of other minor textual
inconsistencies. Naturally, I used the recls-Ruby 
mapping. I wouldn't think of doing it in D!


  This will take nothing short of the community here
 putting its best foot forward to entice new and old developers alike.  It means
 better promotion and more complete projects.  Something high profile would be a
 boon too.


I agree with the projects notion. As soon as I can get my head above water, I
have a rather nifty (C++) code-generator 
to write, and I'm thinking of doing it in D. All those slices are harder to
resist than Willy Wonka's chocolate, or Mrs 
Miggins' pies!


 Also, once we clear V1.0, I expect many to take D more seriously.  In the:.
 meantime, D is stable enough now to accomplish a world of good.


Disagree. It's stable enough to accomplish many small islands of good. There is
a *lot* of work to be done before we're 
onto worlds.

Still, I'm feeling more optimistic about D now than the last month or two, so
let's look forward.

Cheers

Matthew
Sep 09 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <chrfr1$12uc$1 digitaldaemon.com>, Matthew says...

12-18 months ago, there was a happy community and people did indeed exchange
personal/OT debates, and no-one minded.
Indeed, it helped cement relationships and provided some nice entertainment.
People at that time were earnest, but there
was little of the dogma and ego that haunts it now. It may well be that this in
an inevitable part of any movement as it
expands, but I don't think that's entirely covers it.


This is why I suggested a listserv for dev talk, though I'd still like to
believe it's not necessary.  The drama that's gone on here these past few months
is completely unproductive.


I've gone off the idea. I'm now tending towards thinking that we need
Walter/Phobos action on issues, one at a time. I'd
like to see a Library Issue Of The Week, *including* Walter's
attention/involvement. For example, I'd suggest that we
clean up the Exception/Error Hierarchy this week. Why not?


If we can get Walter's participation on core library issues then I'm all for it.
It doesn't have to be anything fancy, but I would like to see some of the core
features (such as exceptions) sorted out in the coming months.


There are some *really* challenging issues ahead, most notably getting DLLs and
GC to work in large-scale/project
scenarios. Until such issues are resolved, D's only going to be good for
implementing stand-alone link-units, or those
that cooperate via C-APIs. (Not that I am troubled by such things, since that's
the only way I use C++, but it's too
much boilerplate and nitty-gritty for a new language to require of its users.)


Yup.  Personally, I think any major project in D right now is kind of putting
the cart before the horse.  They do aid in finding problems in language
implementation, but it's hard to build a castle on sand.  It would be nice to
see more discussion of these and similar issues.  I'm confident that they will
all be addressed, but I'd prefer that be sooner than later :)


Sean
Sep 10 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:chsj13$1kqq$1 digitaldaemon.com...

 In article <chrfr1$12uc$1 digitaldaemon.com>, Matthew says...

12-18 months ago, there was a happy community and people did indeed exchange
personal/OT debates, and no-one minded.
Indeed, it helped cement relationships and provided some nice entertainment.
People at that time were earnest, but 
there
was little of the dogma and ego that haunts it now. It may well be that this in
an inevitable part of any movement as 
it
expands, but I don't think that's entirely covers it.


 This is why I suggested a listserv for dev talk, though I'd still like to
 believe it's not necessary.  The drama that's gone on here these past few
months
 is completely unproductive.


I've gone off the idea. I'm now tending towards thinking that we need
Walter/Phobos action on issues, one at a time. 
I'd
like to see a Library Issue Of The Week, *including* Walter's
attention/involvement. For example, I'd suggest that we
clean up the Exception/Error Hierarchy this week. Why not?


 If we can get Walter's participation on core library issues then I'm all for
it.


Indeed.


 It doesn't have to be anything fancy, but I would like to see some of the core
features (such as exceptions) sorted out in the coming months.


Then *please* apply your considerable expertise to the "Exception hierarchy
refactoring" thread sometime in the next 
couple of weeks. :-)


There are some *really* challenging issues ahead, most notably getting DLLs and
GC to work in large-scale/project
scenarios. Until such issues are resolved, D's only going to be good for
implementing stand-alone link-units, or those
that cooperate via C-APIs. (Not that I am troubled by such things, since that's
the only way I use C++, but it's too
much boilerplate and nitty-gritty for a new language to require of its users.)


 Yup.  Personally, I think any major project in D right now is kind of putting
 the cart before the horse.  They do aid in finding problems in language
 implementation, but it's hard to build a castle on sand.  It would be nice to
 see more discussion of these and similar issues.  I'm confident that they will
 all be addressed, but I'd prefer that be sooner than later :)
Sep 10 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:chj8i6$1vt6$1 digitaldaemon.com...

 "Regan Heath" <regan netwin.co.nz>
 Of course. I agree. However, I have yet to be presented with an approach
 which I would consider better. I have seen the Java way which suffers from
 a potential hidden bug, which IMO makes it a worse solution than what we
 currently have.

 ===================
 On whether that is a bug or something else entirely, I will quote yourself:
 "IMO this example could be a red herring, engineered to show the bug, not
 at all likely in reality"

 I fully agree with your statement Regan. The fact that such a (at best)
 "questionable" example should mandate this direction is beyond the pale :-)

 And what of other, similar, bugs that D doesn't bother to handle? The
 required use of 'override' would catch a bunch of rather nasty, and rather
 common, ones (unlike that "square" example of a particular engineering
 travesty). Yet, 'override' is not required. That kind of argument against
 what you call "the Java way" is somewhat futile on several fronts.



 I doubt very much that I'm alone in that respect.


 No, you're not, quite a few people have expressed dissatisfaction with the
 current system, myself included, however until a 'better' system is
 proposed it will likely remain.

 =====================
 Fair enough. Two notions immediately spring to mind:

 1) How does Java successfully combine method-name resolution with implicit
 primitive conversion? And what is wrong with adopting that model instead, if
 it resolves these problems far more successfully than the existing D
 approach does?

 2) forget about implicit conversion altogether. Even MSVC v6.0 requires me
 to explicitly downcast an int to a char (unless I'm prepared to live with
 warnings, which I'm not).

 Consider this:

 a) isn't it often a sign of inconsistent and potentially buggy design where
 an implicit cast is actually generated? In other cases, it's sheer laziness
 on the part of the programmer. That's not a criminal offence, but support
 for that shouldn't cripple significant aspects of the language either.

 b) D will quietly convert a long argument to an int or char parameter
 without so much as a peep! This is much looser than MSVC, for crying out
 loud ... and should be considered a potential bug, if not an outright one
 (and D is supposed to be more typesafe than C?)


In a language without warnings, that is a bug. Pure and simple.


 c) the implicit conversions of primitive-types makes a total mess of
 overload, especially with respect to inheritance. Just look at some of the
 bizarre examples given in the past for justifying the current
 name-resolution and method-alias scheme <g>

 d) implicit conversion also makes a mess of certain operator-overloads, such
 that the compiler quits with an error message. The same is true of certain
 constructor patterns.


Example(s) please.


 e) method-name alias would not be required, simplifying compiler
 implementation and removing a considerable learning impediment from the D
 language.


Example(s) please.
Sep 08 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <opsdxfc5o15a2sq9 digitalmars.com>, Regan Heath says...

On Mon, 6 Sep 2004 07:16:44 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 In article <opsdvuwlje5a2sq9 digitalmars.com>, Regan Heath says...

 On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias <fu bar.com> wrote:



 Unfortunately, all this implicit conversion conflicts badly with method
 resolution. For instance, if I have two methods:




 the compiler now can't tell which one should be called (vis-a-vis the
 prior example).


 Why does it matter which method is chosen?


 i think antiAlias was referring to current behavior, not future possible
 behavior.


I know. Currently it conflicts, I was suggesting a fix (by asking leading 
questions), it could simply take the first one it finds, as in, if you 
have:

myFunc("hello world");

the constant string has not specific type, so could potentially match any 
of the 3 methods, however, it doesn't matter which method it matches as 
they all (presumably) do the same thing. (*)


I would restrict this a bit, such that if overloads occur within a module then
the first one is chose, but when overloads are encountered across multiple
modules then an error is displayed.  One way to prevent such an error would be
to use explicit module qualifiers.  Here's an example:

module a;

void print( char[] c ) {}
void print( wchar[] c ) {}

module b;

void print( dchar[] c ) {}

module c;
import a;
import b;

print( "hello world" ); // 1
a.print( "hello world" ); // 2

Line 1 is ambiguous because there are multiple valid overloads spanning more
than one module.  Line 2 is unambiguous because module a is specified, so print(
char[] ) will be chosen as it's the first appropriate overload encountered in
module a.  My reasoning is this: if overloads occur within a module then they
are likely intended to serve the same purpose, but if the overloads span modules
then they likely serve different purposes.

I'm still not sure if this overload resolution change may cause more problems
than it solves, but it seems less potentially dangerous than it would be without
the refinement I've suggested.  My only concern is that I don't like special
cases, handling overload resolution differently for string and numeric literals
than for variables seems like kind of a hack.  Would it be appropriate to extend
these rules to overload resolution in general?  I'm inclined to say no, but I'd
have to think about it more before I could say why.


(*) Can anyone think of a potential bug this could cause? to me this 
implicit conversion idea seems identical to the implicit conversion that 
happens between long,int,short etc during method resolution.


True enough.  Then perhaps it isn't that bad.


Sean
Sep 06 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 7 Sep 2004 02:52:51 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:


 In article <opsdxfc5o15a2sq9 digitalmars.com>, Regan Heath says...

 On Mon, 6 Sep 2004 07:16:44 +0000 (UTC), Arcane Jill
 <Arcane_member pathlink.com> wrote:

 In article <opsdvuwlje5a2sq9 digitalmars.com>, Regan Heath says...

 On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias <fu bar.com> wrote:



 Unfortunately, all this implicit conversion conflicts badly with 
 method
 resolution. For instance, if I have two methods:




 the compiler now can't tell which one should be called (vis-a-vis the
 prior example).


 Why does it matter which method is chosen?


 i think antiAlias was referring to current behavior, not future 
 possible
 behavior.


 I know. Currently it conflicts, I was suggesting a fix (by asking 
 leading
 questions), it could simply take the first one it finds, as in, if you
 have:

 myFunc("hello world");

 the constant string has not specific type, so could potentially match 
 any
 of the 3 methods, however, it doesn't matter which method it matches as
 they all (presumably) do the same thing. (*)


 I would restrict this a bit, such that if overloads occur within a 
 module then
 the first one is chose, but when overloads are encountered across 
 multiple
 modules then an error is displayed.  One way to prevent such an error 
 would be
 to use explicit module qualifiers.  Here's an example:

 module a;

 void print( char[] c ) {}
 void print( wchar[] c ) {}

 module b;

 void print( dchar[] c ) {}

 module c;
 import a;
 import b;

 print( "hello world" ); // 1
 a.print( "hello world" ); // 2

 Line 1 is ambiguous because there are multiple valid overloads spanning 
 more
 than one module.  Line 2 is unambiguous because module a is specified, 
 so print(
 char[] ) will be chosen as it's the first appropriate overload 
 encountered in
 module a.  My reasoning is this: if overloads occur within a module then 
 they
 are likely intended to serve the same purpose, but if the overloads span 
 modules
 then they likely serve different purposes.

 I'm still not sure if this overload resolution change may cause more 
 problems
 than it solves, but it seems less potentially dangerous than it would be 
 without
 the refinement I've suggested.  My only concern is that I don't like 
 special
 cases, handling overload resolution differently for string and numeric 
 literals
 than for variables seems like kind of a hack.  Would it be appropriate 
 to extend
 these rules to overload resolution in general?  I'm inclined to say no, 
 but I'd
 have to think about it more before I could say why.


 (*) Can anyone think of a potential bug this could cause? to me this
 implicit conversion idea seems identical to the implicit conversion that
 happens between long,int,short etc during method resolution.


 True enough.  Then perhaps it isn't that bad.


I think I agree with you.. I will have to think about it some more.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 06 2004
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 3 Sep 2004 10:51:58 -0700, antiAlias wrote:


 There was some commentary about the benefits of auto-conversion between
 char[], wchar[] and dchar[], where the compiler will automatically convert
 array literals as it sees fit. So, for example, if you have a method:
 

 
 and call it with:
 

 
 the compiler will convert the literal to a wchar[] instead of a char[]. This
 is apparently considered a GoodThing. Recently, there's been a lot of talk
 regarding additional automatic conversion, between UTF8 and its wchar[] and
 dchar[] representations.
 
 Unfortunately, all this implicit conversion conflicts badly with method
 resolution. For instance, if I have two methods:
 


 
 the compiler now can't tell which one should be called (vis-a-vis the prior
 example). To get around this, one has to cast the string literal like so:
 


 
 Ugly. What some folks do to get around this is to add different method names
 for the same functionality, a la Win32:
 


 
 They are forced into this approach to avoid having to use those ugly casts
 everywhere. This is what Streams.d does, along with others. Okay, so some
 might ask why this is a problem? Well, there are certain method names that
 are fixed in stone by the compiler, and you can't add a suffix even if you
 wanted to:
 





 
 See the problem? The compiler cannot resolve which constructor to use when
 you write
 

 
 Instead, one is forced to use a cast:
 

 
 One can hardly add a "W" suffix to the keyword "this". The same thing
 happens for operator overloads too. One way around this is to introduce
 string prefixes, such as w"this is a wchar string". This has been suggested
 before, and it would certainly get rid of those ugly casts (I was under the
 misguided impression that casts should not be used on a general basis). BTW:
 the w"string" prefix is not a cast; it's a storage-attribute. I'd like to
 suggest such prefixes be supported and adopted.
 
 Anyway; the reason for the post is to make folk aware of the kinds of
 problems introduced when a compiler performs implicit conversions. This is
 bound to become more troublesome if additional "convenience" conversions
 occur implicitly within the D language, such as the oft discussed UTF8
 conversions.
 
 Please consider.


So in the general case, the compiler has to deal with literals in the
source code text. Unless otherwise specified, the compiler needs to work
out how to store and use the literal data. 

D already has suffixes for integer and floating point literals, so the
concept of decorating a literal to express it storage type is not new.

I think that an similar decoration (suffix?) for string literals makes a
lot of sense. 

I also note an inconsistency in DMD. As you point out





will cause a compiler error because it can't workout the type of literal
you are using, but ...





does not cause an error and the compiler actually selects the correct
'myFunc' to use. 

If you argue that in the second case, '2' is always an int and can never be
a long, then why can't "abc" always be a char[] and never a wchar[]? But of
course this breaks down because if 'myFunc(int)' was not defined then the
literal '2' is assumed to be a long and not an int.

Inconsistent and not documented, I think.

-- 
Derek
Melbourne, Australia
7/Sep/04 9:50:33 AM
Sep 06 2004
prev sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <chaapt$1rac$1 digitaldaemon.com>, antiAlias says...

There was some commentary about the benefits of auto-conversion between
char[], wchar[] and dchar[], where the compiler will automatically convert
array literals as it sees fit. So, for example, if you have a method:



and call it with:



the compiler will convert the literal to a wchar[] instead of a char[]. This
is apparently considered a GoodThing. Recently, there's been a lot of talk
regarding additional automatic conversion, between UTF8 and its wchar[] and
dchar[] representations.

Unfortunately, all this implicit conversion conflicts badly with method
resolution. For instance, if I have two methods:




the compiler now can't tell which one should be called (vis-a-vis the prior
example). To get around this, one has to cast the string literal like so:




Ugly. What some folks do to get around this is to add different method names
for the same functionality, a la Win32:




They are forced into this approach to avoid having to use those ugly casts
everywhere. This is what Streams.d does, along with others. Okay, so some
might ask why this is a problem? Well, there are certain method names that
are fixed in stone by the compiler, and you can't add a suffix even if you
wanted to:







See the problem? The compiler cannot resolve which constructor to use when
you write



Instead, one is forced to use a cast:



One can hardly add a "W" suffix to the keyword "this". The same thing
happens for operator overloads too. One way around this is to introduce
string prefixes, such as w"this is a wchar string". This has been suggested
before, and it would certainly get rid of those ugly casts (I was under the
misguided impression that casts should not be used on a general basis). BTW:
the w"string" prefix is not a cast; it's a storage-attribute. I'd like to
suggest such prefixes be supported and adopted.

Anyway; the reason for the post is to make folk aware of the kinds of
problems introduced when a compiler performs implicit conversions. This is
bound to become more troublesome if additional "convenience" conversions
occur implicitly within the D language, such as the oft discussed UTF8
conversions.

Please consider.


antiAlias: To reiterate, I think your initial points that started this thread
are on the money...also I'm not quite sure I understand how the thread took a
hard right and then a nose dive soon after you posted it. But do hope Walter
will fix this soon, with maybe adding the prefixes w"" and d"" for string
literals, which should solve both the parameter passing and string concatenation
(~) problems when using string literals. Well here's hoping anyway! 

Also, I think we all need a *Big Group Hug*. Let's all get back to supporting
"D" and each other in very positive ways!!  :))

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Sep 10 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"David L. Davis" <SpottedTiger yahoo.com> wrote in message
news:cht3o7$1u1n$1 digitaldaemon.com...

 In article <chaapt$1rac$1 digitaldaemon.com>, antiAlias says...

There was some commentary about the benefits of auto-conversion between
char[], wchar[] and dchar[], where the compiler will automatically convert
array literals as it sees fit. So, for example, if you have a method:



and call it with:



the compiler will convert the literal to a wchar[] instead of a char[]. This
is apparently considered a GoodThing. Recently, there's been a lot of talk
regarding additional automatic conversion, between UTF8 and its wchar[] and
dchar[] representations.

Unfortunately, all this implicit conversion conflicts badly with method
resolution. For instance, if I have two methods:




the compiler now can't tell which one should be called (vis-a-vis the prior
example). To get around this, one has to cast the string literal like so:




Ugly. What some folks do to get around this is to add different method names
for the same functionality, a la Win32:




They are forced into this approach to avoid having to use those ugly casts
everywhere. This is what Streams.d does, along with others. Okay, so some
might ask why this is a problem? Well, there are certain method names that
are fixed in stone by the compiler, and you can't add a suffix even if you
wanted to:







See the problem? The compiler cannot resolve which constructor to use when
you write



Instead, one is forced to use a cast:



One can hardly add a "W" suffix to the keyword "this". The same thing
happens for operator overloads too. One way around this is to introduce
string prefixes, such as w"this is a wchar string". This has been suggested
before, and it would certainly get rid of those ugly casts (I was under the
misguided impression that casts should not be used on a general basis). BTW:
the w"string" prefix is not a cast; it's a storage-attribute. I'd like to
suggest such prefixes be supported and adopted.

Anyway; the reason for the post is to make folk aware of the kinds of
problems introduced when a compiler performs implicit conversions. This is
bound to become more troublesome if additional "convenience" conversions
occur implicitly within the D language, such as the oft discussed UTF8
conversions.

Please consider.


 antiAlias: To reiterate, I think your initial points that started this thread
 are on the money...also I'm not quite sure I understand how the thread took a
 hard right and then a nose dive soon after you posted it. But do hope Walter
 will fix this soon, with maybe adding the prefixes w"" and d"" for string
 literals, which should solve both the parameter passing and string
concatenation
 (~) problems when using string literals. Well here's hoping anyway!

 Also, I think we all need a *Big Group Hug*. Let's all get back to supporting
 "D" and each other in very positive ways!!  :))


Ok. All, consider yourself on the receiving end of some big love from Bigboy. ;)
Sep 10 2004