Michel Fortin wrote:
> On 2010-02-18 12:18:47 -0500, Martin Franklin <martin246564@btinternet.com> said:
> 
>> Its time to dump C-like languages - I have the evidence.
>>
>> http://www.modulaware.com/mdlt28.htm
> 
> Nice read...

Very interesting indeed. It was written in 1992 and it's really fascinating to put this in historical perspective, considering what happened to the languages involved.

As they say in chess - never ignore the whole for the beauty of the part.


Andrei

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:hlk4le$13ht$1@digitalmars.com...
> On 2010-02-18 12:18:47 -0500, Martin Franklin <martin246564@btinternet.com> said:
>
>> Its time to dump C-like languages - I have the evidence.
>>
>> http://www.modulaware.com/mdlt28.htm
>
> Nice read... and it gives me a new feature idea for D! The article rants about default parameters not being very useful when you have more than one (something I agree with), then propose an improvement:
>
>> Furthermore, they do not provide a great deal of convenience. If a routine has five parameters, the last three of which are optional, and caller wants to assume the defaults for parameters 3 and 4, but must specify parameter 5, then all five parameters must be specified. A better scheme would be to have a default keyword in function calls:
>>
>> f (a, b, default, default, e);
>
> Would't that be nice to be able to use the 'default' keyword when you want to use the default value for a parameter? Should be pretty trivial to implement.
>

VBScript (Or maybe it's just VB6. Not sure about VB.NET) allows the above by doing this:

f (a, b, , , e)

That's the one thing about VB that I actually kinda liked. Of coruse, it may not be a perfect approach, but at least you *can* leave middle params as default.

On 2010-02-21 21:50, Nick Sabalausky wrote:
> VBScript (Or maybe it's just VB6. Not sure about VB.NET) allows the above by
> doing this:
>
> f (a, b, , , e)
>
> That's the one thing about VB that I actually kinda liked. Of coruse, it may
> not be a perfect approach, but at least you *can* leave middle params as
> default.

Yeah, I like that feature too (I have to use VB a lot for work; I freely admit to being something of a "quiche-eating" programmer, with aspirations to D). Note that VB 4-6 (and probably earlier), VBScript, and VB.NET all allow that syntax. In fact, C# programmers apparently liked it as well; it's a feature that was recently added to C# 4, which is still in beta.

-- 
‖ Insert clever saying here… ‖ http://tagzilla.mozdev.org v0.066

Nick Sabalausky:

> "Michel Fortin
> >> f (a, b, default, default, e);
> f (a, b, , , e)

The syntax with just commas is shorter but you can miss commas, so I prefer the version with the default keyword, because it's more syntactically visible by the programmer's eye. Here saving the 'default' keystrokes doesn't look like an improvement.

I'd like to have named function arguments, even if partially implemented (there are cases with delegates/function pointers where you need to do more changes if you want to fully support named arguments, I've discussed this in the past. Such cases can be omitted in the first implementation of this feature), because in some situations they can increase code readability, and code readability can lower bug count and increase coding speed. (I don't know how the last C# has implemented this feature).

Named arguments and that syntax to omit default arguments in the middle can be used for similar purposes:
void foo(int a=1, int b=2, int c=3) {...}
foo(5, , 3);
foo(5, default, 3);
foo(a=5, c=3);
foo(5, c=3);

But this feature can be added later, I think it's an additive change. What's instead more important to discuss first are features for D2 that can't be just be added later, because they aren't just additive changes because they need changes not backwards compatible with D1 (or with the precedent version of D2). This is how the list of changes in Python3 was chosen: the minimal number of changes that are not backwards compatible with Python2.x minus the additive changes. All the other things that can be just added were postponed to Python3.1 or later. This is a good design strategy that I have not seen explicitly expressed in this newsgroup :-( I am sorry for not thinking and writing this comments few months ago, because now it's not that useful.

Bye,
bearophile