Arcane Jill wrote:
> I also concur with the person on wiki who suggested that all functions with
> default arguments be implicitly final. (Or even explicitly, if you really want
> to make a point). Overloading is common, and default arguments are common, but
> overloading and default arguments at the same time are rare enough that this is
> unlikely to be much of a problem.

I completely disagree! Default arguments are even more needed for interfaces than for normal classes, since without them EVERY implementation has to include all the dummy functions.

A better rule would be that all overloads simply have to define the same default arguments. The default shouldn't change depending on the context in which the function is called anyway.


Hauke

Arcane Jill wrote:
> I also concur with the person on wiki who suggested that all functions with
> default arguments be implicitly final. (Or even explicitly, if you really want
> to make a point). Overloading is common, and default arguments are common, but
> overloading and default arguments at the same time are rare enough that this is
> unlikely to be much of a problem.

I would rather it be illegal to provide defaults on any method that is an override, including interface implementations. (by extension, then, interfaces would be allowed to provide defaults)

 -- andy

Andy Friesen wrote:
> Arcane Jill wrote:
> 
>> I also concur with the person on wiki who suggested that all functions with
>> default arguments be implicitly final. (Or even explicitly, if you really want
>> to make a point). Overloading is common, and default arguments are common, but
>> overloading and default arguments at the same time are rare enough that this is
>> unlikely to be much of a problem.
> 
> 
> I would rather it be illegal to provide defaults on any method that is an override, including interface implementations. (by extension, then, interfaces would be allowed to provide defaults)

Just to make sure I understand: you mean the override must not specify defaults because it will implicitly inherit the ones from the original defintion, correct?

I would prefer that the defaults have to be explicit, but always the same as the original ones. That way they can be seen without having to look at any base classes.

Also, your system has another problem: what if two interfaces define the same function with different defaults? Then there are two "original" definitions, so this needs to be handled specifically.

If you require the overloads to have the same defaults then this case is automatically handled, because no overload can have the same defaults as both the methods it overrides. I.e. it is not possible to implement both interfaces in the same object, which is the only solution I can see. It would be the same as if the interfaces defined methods with the same parameter lists but different return values.

Hauke

Hauke Duden wrote:
> Andy Friesen wrote:
> 
>> I would rather it be illegal to provide defaults on any method that is an override, including interface implementations. (by extension, then, interfaces would be allowed to provide defaults)
> 
> 
> Just to make sure I understand: you mean the override must not specify defaults because it will implicitly inherit the ones from the original defintion, correct?

Exactly.

> I would prefer that the defaults have to be explicit, but always the same as the original ones. That way they can be seen without having to look at any base classes.

My first instinct is to agree that a bit of syntactic salt would be a good thing, but, on second thought, it means duplication, which is Very Bad.

> Also, your system has another problem: what if two interfaces define the same function with different defaults? Then there are two "original" definitions, so this needs to be handled specifically.

In such a case, the two functions are distinct, even if they happen to have the same name.  There is no conflict.

 -- andy

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c9d9v1$hdd$1@digitaldaemon.com...
> Walter wrote:
> > One can overload functions from different import scopes using the
'alias'
> > capability. I believe this explicit control over function overloading is better than C++ for handling very large programs - in C++ with its
global
> > overloading and ADL one can get really lost as to which functions are
'in
> > play' for overloading.
> Well, when you use alias you always have to manually "prepare" the aliases for all overloaded functions you want to use. That makes it impossible to use two modules in combination by simply importing them
both.

No, you just need to do one alias per imported name. Not one for each overload of each function. The alias pulls in all the functions of the same name.

> > That's to create a bool from an int. This overhead isn't there once it
is a
> > bool. I don't know of any conceivable implementation of bool (and that includes C++'s bool) that doesn't have this overhead in converting to a bool.
> If a bool is simply a 32 bit value where 0 means false and !=0 means true then no conversion is necessary.

Then just use an int. I just don't see what the problem is.

> But in my experience bool variables are very rarely compared to each other. Most of the time they are set to true or false or their true-ness is checked. There is no additional overhead for this.

And there is none in D.

> In fact, I believe such a bool allows the compiler to do additional optimizations, like the one you did manually with "islower". Only when the bool is explicitly converted to an int should the compiler perform the conversion !=0 => 1.
>
> I think such a bool as a distinct type without implicit conversions to and from integers would be the best possible way to do it.

It just doesn't set well with me that two values of a type can compare 'equal' yet contain entirely different bit patterns.


> > I have been surprised at the amount of controversy over a bool type
(Matthew
> > is solidly in your camp on this, too!). I recall many l-o-n-g threads in newsgroups over the semantics of bool to C years ago.
>
> So why are you surprised? :)

I was surprised then, too. It's just much ado over next-to-nothing. (I argue about this with Matthew, too <g>.) One thing that is clear, though, is that there's no agreement at all.


> I never encountered any situation where I needed to use a bool as an integer in pure C++ or JAVA code. The only thing that comes close is when interfacing with C code that expects an int instead of a bool. But that is mostly a problem of C++ because it is source code compatible with C. D has the opportunity to break with this, since it only needs binary compatibility with C.

bool has been added to both C and C++, so if there was an obvious semantic meaning for it, such would have been chosen. But there was no consensus on what the 'obvious' semantics should be. People continue to fruitlessly argue about it. I'd rather move on <g>.


> > A good point. But also consider that I wouldn't have created this
newsgroup
> > if I wasn't interested in other peoples' views. D has grown and improved
a
> > lot based on feedback from the members here. But the risk D runs in
trying
> > to please everyone is becoming a mish-mash of conflicting, overlapping features.
> I know and I am constantly surprised when you release a new DMD version
> and a lot of NG ideas are in there. I also realize that you need to try
> work through all the suggestions to see which features are REALLY needed
> by many people.
> But sometimes it seems that there are lots of people in the NG who all
> agree that something should be changed and there is no comment from you
> anywhere to be seen. Which doesn't mean that you don't listen, of
> course, because a month later this feature may very well be in the
> language. Or it may not because you have never had a problem with it
> yourself (see switch).

The problem is I'm a thousand or two messages behind in reading the n.g. Even when I do post replies, that frequently inspires a whole ream of new postings. So the more I read and post, the further I get behind. I'm currently trying to wrap up reading the January postings. I'm not complaining, however, since the huge volume of messages is a wonderful sign of the health of the D community!


> Just to avoid misunderstandings: I believe every language should be designed by a single individual, since the compromises you get with design groups are often worse than the simple bad decisions a single person can make.

Design-by-committee suffers from the "vote for my feature and I'll vote for yours" madness. And it still is no guarantee that wretched misfeatures won't get in the language, I submit C++'s 'export' as the canonical example <g>. That said, there is still a time and a place for a standards committee for a language, but that is after it is designed and all major features are in place.


> I think your model of "eaves-dropping emperor" is really one of the better ones. But sometimes I wish you'd at least give some feedback when you have been convinced of something, so that we can stop and do something more productive :). A page of features that are on your todo list for a future version of DMD would be great.

I keep thinking I'm done with 1.0 features <g>.

>> > A good point. But also consider that I wouldn't have created this
> newsgroup
>> > if I wasn't interested in other peoples' views. D has grown and improved
> a
>> > lot based on feedback from the members here. But the risk D runs in
> trying
>> > to please everyone is becoming a mish-mash of conflicting, overlapping features.
>> I know and I am constantly surprised when you release a new DMD version
>> and a lot of NG ideas are in there. I also realize that you need to try
>> work through all the suggestions to see which features are REALLY needed
>> by many people.
>> But sometimes it seems that there are lots of people in the NG who all
>> agree that something should be changed and there is no comment from you
>> anywhere to be seen. Which doesn't mean that you don't listen, of
>> course, because a month later this feature may very well be in the
>> language. Or it may not because you have never had a problem with it
>> yourself (see switch).
> 
> The problem is I'm a thousand or two messages behind in reading the n.g. Even when I do post replies, that frequently inspires a whole ream of new postings. So the more I read and post, the further I get behind. I'm currently trying to wrap up reading the January postings. I'm not complaining, however, since the huge volume of messages is a wonderful sign of the health of the D community!
> 
> 
>> Just to avoid misunderstandings: I believe every language should be designed by a single individual, since the compromises you get with design groups are often worse than the simple bad decisions a single person can make.
> 
> Design-by-committee suffers from the "vote for my feature and I'll vote for yours" madness. And it still is no guarantee that wretched misfeatures won't get in the language, I submit C++'s 'export' as the canonical example <g>. That said, there is still a time and a place for a standards committee for a language, but that is after it is designed and all major features are in place.
> 

If not special care at taken the intelligence of a group is often the average of its members.

To solve this I have created what I call an eigenpoll.
http://all-technology.com/eigenpolls/

If you like I will make one for D suggestions.

Knud

Walter wrote:
>>If a bool is simply a 32 bit value where 0 means false and !=0 means
>>true then no conversion is necessary.
> 
> 
> Then just use an int. I just don't see what the problem is.

Because int and bool are completely different types. True bools prevent errors, like the often seen newbie problem "while(x=7)". That would not be possible if "while" required a true boolean.

>>But in my experience bool variables are very rarely compared to each
>>other. Most of the time they are set to true or false or their true-ness
>>is checked. There is no additional overhead for this.
> 
> 
> And there is none in D.

Well if there is none then why don't you use bool for islower? It clearly returns a boolean value (true or false), yet you use int because using bool/bit would be slower.

If there was a real boolean type then the compiler would have the freedom of doing such optimizations implicitly by just considering any nonzero value as true.

> The problem is I'm a thousand or two messages behind in reading the n.g.
> Even when I do post replies, that frequently inspires a whole ream of new
> postings. So the more I read and post, the further I get behind. I'm
> currently trying to wrap up reading the January postings. I'm not
> complaining, however, since the huge volume of messages is a wonderful sign
> of the health of the D community!

Would it help if volunteers posted summaries of dead threads? Presenting all arguments and counter-arguments in a condensed manner?


Hauke

Andy Friesen wrote:
 >> I would prefer that the defaults have to be explicit, but always the
>> same as the original ones. That way they can be seen without having to look at any base classes.
> 
> 
> My first instinct is to agree that a bit of syntactic salt would be a good thing, but, on second thought, it means duplication, which is Very Bad.

No, duplication is good if the "other copy" is in a different class.

Otherwise, when you see a method

foo(int a,int b)

in a class, how do you know how you can call it? Is there a default value for a or b? What is it?

To find out you'd have to look in all base classes and see if they contain a function foo(int,int). That is what I consider bad.


>> Also, your system has another problem: what if two interfaces define the same function with different defaults? Then there are two "original" definitions, so this needs to be handled specifically.
> 
> 
> In such a case, the two functions are distinct, even if they happen to have the same name.  There is no conflict.

Urgh!!! So what happens if you have foo(int a=0) and foo(int a=5)? Which default value is chosen when someone calls foo()?

And how'd you overload these two distinct functions without duplicating the default values? How do you indicate which one to overload?

I don't think this can work.

I think the only sensible solution is that different defaults are a conflict and that all overloads must specify the same defaults as the base class function they are overloading. It is easy to read, immediately understandable, typos are caught at compile time and function calling is unambiguous.


Hauke

Knud Sørensen wrote:
> If not special care at taken the intelligence of a group is often the average of its members.

One of my favorite authors (Terry Pratchett) wrote that
"the IQ of a mob is the IQ of its dumbest member divided by the number of participants".

It is not quite the same for academic working groups, but there is a similar tendency ;).

Hauke

Hauke Duden wrote:

> ... when you see a method
> 
> foo(int a,int b)
> 
> in a class, how do you know how you can call it? Is there a default value for a or b? What is it?
> 
> To find out you'd have to look in all base classes and see if they contain a function foo(int,int). That is what I consider bad.

In almost all cases, this would be the direct parent, the uppermost base class, or an interface.  Hopefully, it would almost always be an interface or abstract class. (implementation inheritance is scary)

>>> Also, your system has another problem: what if two interfaces define the same function with different defaults? Then there are two "original" definitions, so this needs to be handled specifically.
>>
>> In such a case, the two functions are distinct, even if they happen to have the same name.  There is no conflict.
> 
> Urgh!!! So what happens if you have foo(int a=0) and foo(int a=5)? Which default value is chosen when someone calls foo()?

Waaait a second.  I had no idea that two interfaces could 'overlap' in this way.

Since foo() is the same method for both interfaces, the defaults should necessarily coincide.  If they don't, it's probably a bug anyway. (even if it isn't, it sure looks like one)

> I think the only sensible solution is that different defaults are a conflict and that all overloads must specify the same defaults as the base class function they are overloading. It is easy to read, immediately understandable, typos are caught at compile time and function calling is unambiguous.

It has real potential to be a maintenance nightmare if a default has to change, however.

I think I see why Walter wanted to leave these out. :)

 -- andy