Named parameter HORROR

Question

Created Jun ’15

Replies 19

Boosts 0

Views 5.6k

Participants 13

Two days into my Swift (2) experience...

func X( a:Int,  b:Int) {
    print(a,b)
}

X(  1,   2) // error: missing argument label 'b:' in call
X(a:1,   2) // error: incorrect argument labels in call (have 'a:_:', expected '_:b:')
X(  1, b:2) // ok
X(a:1, b:2) // error: extraneous argument label 'a:' in call

Horror!

😢😮😠😕😟➖⚠✖

And I *never* use Emoji.

Contrast this with:

print( [1,2,3].contains(2) )

Perfect, I didn't know any of that syntax. But that's what I would expect. That's 'Pythonic'. Writing out my idea in straight pseudocode, and it works! Isn't that the goal of all of this? Getting the most natural effortless straightforward syntax?

That "named parameter mess" reminds me of C++, where everything breaks down into a zillion edge cases.

(On a side note, I wasted a lot of effort trying to get named parameters past the C++ committee. So there is some irony in the fact that although Swift has done it, it has in-so-doing created a C++-style awfulness).

I am making a bad smell here for a reason. Because I've watched the videos, I've read the book introduction. From my experience with C/ObjC/C++/C#/Python/JavaScript I love what's going on -- the idea of starting from scratch making a truly modern language with Pythonesque grace and C-like performance. The moment the opensource move hit of the news I jumped on it.

If I didn't think it was a great language I wouldn't complain. I would just silently walk away.

But we can't have fugliness like this.

All 4 of those cases should work. So that whether or not you supply a name for an argument is up to you.

drawCircle(position: myPosition,  radius: myRadius) // BAD -- duplication is ugly
drawCircle(myPosition, myRadius, borderWidth:1)     // GOOD

That's zen.

I'm sure there is some longwinded explanation for why the above catastrophe has happened. I'm not interested. I just want to see it gone. I want to teach this language to children.

I can see clearly the vision of Swift, and I am concerned the reality keeps to it.

π

Boost

Answer 1

p-i- OP

Jun ’15

What you say makes no sense, moreover it sounds like a rant.

Without force the same sucking coders writing junk in C++ will just do the same in Swift.

Are you referring to C++'s lack of named parameters? Bjarne (and other committee members) directly shooting down any proposal to remedy that ugliness is a huge frustration. But "sucking coders writing junk" -- the language forces them to write unclear code. It is not the fault of the programmers.

You assume that when they move to a language that DOES support named parameters, they will now deliberately omit parameter names because that is what they are used to? And it would have to be deliberate, because the default behaviour is to require the name at the call site. To allow a direct (unnamed) parameter, `_` is necessary.

That is absolute nonsense. It is an absurd assumption.

A competent programmer uses the available tool set in the best way possible.

And one should not obfuscate a new language in order to pander to incompetent people. It is a grave mistake to make the language more clumsy for a competent programmer so as to steer the incompetent away from pitfalls. Expect competence! Insist upon it! These people should be the target of the language. It should be optimised for these people. Because it is these people that are the movers and shakers.

There are always going to be lazy, undisciplined, incompetent, etc. people on the borderline. If you concede to encompass those, you will have a new borderline. And a new set of slightly lazier, less disciplined and more incompetent people. It's a slippery slope.

The best way to serve everyone is to make the language as simple and straightforward as possible. If there is an opportunity to replace a twisted-up syntax with a clean concise syntax, and there is no downside, that opportunity should be taken.

Nobody has yet illustrated a downside to the syntax I have suggested.

0

Answer 2

EoinN OP

Jun ’15

If you didnt require labels very few callers would use them.

You are right about case 3 and 4 however. 3 is ok as a convience to not force the labelling of the first item, however you should be able to add the label or not.

However I think they are both trying for compatibility with Obj C and encouraging good naming conventions in the method or function names, the method names should explain what the first paramater is, and it should be the *main* paramater, the most important param if that is measurable.

func attributesOfItemAtPath(_

path

: String) throws -> [String : AnyObject]

rather than

func attributesOf(_

path

: String) throws -> [String : AnyObject]

0

Answer 3

vjosullivan OP

Jun ’15

"A competent programmer uses the available tool set in the best way possible."

Whilst true, it's always worth remembering that 50% of programmers are of below average competence (and many more are not much better).

0

Answer 4

LCS OP

Jun ’15

>> Nobody has yet illustrated a downside to the syntax I have suggested.

Given the fact that the vast majority of Swift code will be interacting with Apple frameworks still written in objective-C for the near future, using a label syntax that makes automatic translation of Swift methods <-> objC methods more difficult would probably qualify as a downside to the syntax you suggested.

0