Discussion: Type inference about swift-style-guide HOT 12 CLOSED

Option+Click on something and it tells you the type. :-)

from swift-style-guide.

Option+Click on something and it tells you the type. :-)

Does that work when reading tutorials on Ray Wenderlich's site ;-)

from swift-style-guide.

Apple should build a Playground that you can embed in websites. :-)

In all seriousness, I think you can often tell from the context (i.e. the surrounding code) what the type should be.

from swift-style-guide.

Unfortunately this is a debate we may never fully agree on. See this thread regarding exactly the same topic with c#

http://stackoverflow.com/questions/41479/use-of-var-keyword-in-c-sharp

from swift-style-guide.

I am in favor of readability, so I propose to have explicit types, at least in this first period of transition from Objc to Swift.

from swift-style-guide.

at least in this first period of transition from Objc to Swift

I expect that the practices we establish now will be used by people for a long time, simply because they get copied and pasted over and over. There may be a danger in that.

I vote for teaching people to do it the Right Way™ from the start. (Of course, no one yet knows what the Right Way™ is, but in my opinion it is not being scared of the new language.)

from swift-style-guide.

I am in favor of readability, so I propose to have explicit types, at least in this first period of transition from Objc to Swift.

But that can lead to some hideous code ...

var complexType: Dictionary<Int,Array<String>> = soSomethingClever()
var complexType: (T: AnyType, U:Array<T>) -> (Bool) = functionFactory()

from swift-style-guide.

Kinda hard to set in stone what we find out along the way :)
I think this guideline is gonna go through many iterations before getting stable so I'd not consider anything we agree on today as final.

@ColinEberhardt That code is hideous but at least it's clear and I don't need to check out any documentation/implementation to find out about the type of complexType.

from swift-style-guide.

I think we'll get better at this as we write more real world code. :-)

from swift-style-guide.

Once again, I think we should be following Apple's lead here.

In every video session I saw, they inferred types wherever possible. They even showed it with the type sometimes and then explicitly removed it and pointed out how much better it was.

I think they are going for concise by default, and if we hold on to things like types and parameter names because they are what we're used to, then our code will look out if date.

So my vote is no types anywhere unless the code doesn't work without it, even if it seems odd to us at first.

Sent from my iPhone

On Jun 10, 2014, at 6:03 AM, Matthijs Hollemans [email protected] wrote:

I think we'll get better at this as we write more real world code. :-)

—
Reply to this email directly or view it on GitHub.

from swift-style-guide.

Once again, I agree with @elephantronic.

Using inferred types seems like the preferred option to me. Although, being a control freak I'm a little nervous about it, but I really do think it's the right thing to do unless there's some clear reason not to do it.

from swift-style-guide.

Agreed to use inference where possible. As long as we don't skip out on expressive variable and function names, it should make sense. I think it'd be best to strive for human readability, not necessarily technical readability.

from swift-style-guide.