Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Thoughts on SWIFT type inferrence
- Thread starter AdonisSMU
- Start date
- Sort by reaction score
Obviously you can always declare the type if you want. You should always be able to tell what type the compiler's inferring. It's just meant to shorten the typing and the line lengths.
I've worked with a language lately that has a kind of the opposite opinion on types. The language doesn't require you to use types (much). It figures out the types at runtime, if it needs to. What I've found is that for function prototypes it's useful to have types. For local variables it's almost always obvious what the type is so specifying it there isn't so important. This is especially true if your methods are only a few lines.
I've worked with a language lately that has a kind of the opposite opinion on types. The language doesn't require you to use types (much). It figures out the types at runtime, if it needs to. What I've found is that for function prototypes it's useful to have types. For local variables it's almost always obvious what the type is so specifying it there isn't so important. This is especially true if your methods are only a few lines.
Code:
let myName = "ArtOfWarfare"vs
Code:
let myName: String = "ArtOfWarfare"(Might be typos - I haven't written any Swift code in about a week).
Call me crazy, but I think it's fairly obvious what the type of myName was - I really didn't need to type it.
Really, what I'm glad is gone is things like:
Code:
NSColor *color = [NSColor colorWithWhite:0.3];I mean, really, how many times can it possibly be necessary to type color?
Code:
let color = Color(white:0.3)(Again, I might have mistakes here.)
Is so much cleaner. Perhaps it's the tiniest bit less expressive (not really), but it's now faster to read because it can easily be read without moving your eyes - beyond ~70-80 characters your eyes start having to move back and forth as you scan from line to line which takes the brain substantially longer to process.
What about as it relates to closures, return types etc...
I like intentions to be clear rather than implied particularly as it relates to functions, closures etc....
----------
I like intentions to be clear rather than implied particularly as it relates to functions, closures etc....
----------
This is what I was thinking but I wanted to hear other opinions...
Type Inference is better than being completely dynamic, like Python, in my opinion. In Python, I find it next to impossible to determine the types many functions will return since function declarations don't mention their input or output type. It's not uncommon for a function to just return something it got from another function, so I end up having to read through several function implementations just to see the type that a single function will return.
Although I guess that's not pertaining to type inference but type safety...
Although I guess that's not pertaining to type inference but type safety...
I certainly agree Type Inference is better than being completely dynamic for sure.
There are so many short cuts shoe horned into SWIFT via closures and functions that I could easily see how one could come back to code written awhile ago and no know what is going on. There is even type inference for return types or better yet return can be implied in SWIFT.... eeeek! I'm not sure how I feel about that. More tools at your disposal is better than less. However, sometimes you could actually trigger one of these shortcuts to happen and not realize where the bug is in your code.
Last edited:
If you have a two line closure then things will be obvious.
If you are iterating over list of Strings or a Map/Dictionary then the parameters will be clear. It's only when you've got some other kind of closure that you might need/want the parameters to be spelled out. I've seen some complaints about the closure syntax on the Apple forum related to this case.
If you are iterating over list of Strings or a Map/Dictionary then the parameters will be clear. It's only when you've got some other kind of closure that you might need/want the parameters to be spelled out. I've seen some complaints about the closure syntax on the Apple forum related to this case.
Actually, that's wrong. Less is better. Perfection is achieved when there's nothing more that you could remove and still have the product you want. Keep It Simple.
And that's the issue with Swift. This is only version 1 and it already seems to be quite complex. There's way too many different things.
IE: Classes, Structs, and Enums. I get Classes and Enums, but Structs seem to add a lot of complexity with little return value.
Or the complexity of naming variables in functions (I can't remember all the rules right now... something about a # and inserting spaces and underscores...)
Or what the heck is that whole chapter on Initializers that can and can't be inherited and blah blah blah?
It looks like they've got a better language with Swift than Obj-C/C/C++ all were... and maybe it's even better than Java/JavaScript... but it seems to me that there's nothing Swift does well that Python can't do as well or better, and yet Python is a much cleaner, simpler language.
Well... we'll see how this goes.
Back to type inferrence, I don't think you're familiar enough with a wide enough variety of languages.
There are type-safe languages, like Java, where for the most part everything is checked at compile time. I say for the most part because unlike Swift's compiler, Java's compiler completely ignores the possibility of null values. As a result, we have every Java programmer's favorite runtime error, the NullPointerException. Alternatively, you can cover your Java code in checks for nulls and error handling. All because the language allows anything to be null and won't check for the possibility at all as part of compilation.
The other huge flaw in Java's type system is that casts are assumed to be valid by the compiler and result in runtime errors if they fail. Again, you can either allow that to happen or cover your code in explicit type checks and error handling because the compiler doesn't handle this kind of check for you.
That's what makes Swift's optional type genius. Theoretically, we'll never see either of Java's huge flaws here, because of optionals. The compiler will verify that optionals are checked before unwrapped (unless you force it to unwrap without a check - but that's a conscious design choice by the programmer, not a mistake like forgetting to check before using it in Java). It'll check before casting.
Then there's the readability of Java. Java isn't quite as bad as Obj-C at being repetitive, but it's pretty bad, where often you'll have the exact same class name be on the left and right side of every equality.
Swift fixes that with type inference. The type name is already on the right in most cases, so you don't need it on the left. Or the name of the type is provided as the return type of what you're calling on the right side, so you don't need it on the left. Or you're using literal syntax on the right, so you don't need it on the left. This does away with the needless redundancy.
So I was mistaken a few minutes ago when I said Swift has nothing on Python. They have type safety on Python. Python has no compilation step at all, so Swift may end up beating it not by virtue of being a cleaner language (because it definitely isn't), but by being a type-safe language that isn't simultaneously retarded (not checking casts or for nulls) and overbearing (requiring type names everywhere) like Java.
I agree that simplicity is good and important. I worry that swift is already too complicated. Complexity is one of the things I dislike about c++. After living with Obj-C's loose typing for a while I decided that type safety, as promoted by c++ zealots, is overrated. Aside from some ugly syntax, templates in c++ are one complex ugly mess. And we now have something similar in swift generics.
swift seems quite coercive and in some places arbitrary. Is this really a compiler error:
?
swift seems quite coercive and in some places arbitrary. Is this really a compiler error:
Code:
let d = .5?
I've never heard someone call C++ type safe before.
Obj-C suffers from a lot of the same issues that Java does, despite being a dynamic language. Things can surprise you and be null at runtime, or not be the type you expect them to be so casting fails. Those kinds of mistakes become runtime errors, whereas in Swift they'll be compile errors. Since it checks for those mistakes as you type your code, you'll be alerted to the issue the moment you write the code, meaning you'll be able to fix it swiftly.
In contrast, being told about the error when you go to compile means you need to go back to that code and remember what you just wrote and fix it.
Or even worse, being told about the error at runtime means you have to go back to code you potentially haven't touched in quite a while (if you're working on a team project, maybe someone entirely else wrote it), remember how it all works, and then fix it.
So the sooner mistakes are caught, the easier and quicker they are to fix. Going from being caught eventually at runtime (as in a dynamic language, or even supposedly type-safe language like Java) to being caught right as you fix it (as in Swift when you're using Xcode 6) should be amazing for productivity.
Have you used Groovy or Python? c++ is type safe by comparison. You need to specify types, although you can use typecasts to get around the type system.
Your comments are the usual things one hears about compile time errors vs runtime errors. Good programming practices helps you to avoid the runtime errors. I rarely see runtime errors due to a wrong type. My arrays almost always have contents of the same type. I have a modest amount of code that has to check a type before using the object.
You might be right that swift's strong type safety will result in cleaner code. I'm willing to be convinced. The fact that mixed mode arithmetic is forbidden also seems coercive.
----------
Which is a bug? That the code I showed doesn't compile or that the language doesn't allow that code? I think it's a language decision that doubles need a digit before the decimal point. This code is valid:
Code:
let d = 0.5while this is illegal:
Code:
let d = .5
It would appear that it's attempting to interpret that as an enum identifier, to me.
But as far as I recall, you aren't allowed to start them with a digit.
I think maybe Apple should've picked a different character to denote enums maybe # or > rather than . for enums... Either way 0 is implied and should be implied always in the case of .5. not being able to assign .5 to a variable is confusing IMO.
I don't think it's confusing it as an Enum though as that enum syntax only works on variables that have already been established as a member of an enum type.
Creating the static it's typeless until it can infer a type and can't infer a type from .5 Which it doesn't infer as a number as all numbers start with a number character.
I think the point is in Swift anything that starts with a punctuation character is an operator of some kind. Which is kind of neat in that it allows user defined operators constructed from a group of punctuation characters
Away from computer I can test at but does either of these work?
Code:
let d = ++5
or
let d = 5++Or does the compiler need to infer a type before it can operate on it like in the the second.
Both of those will fail because the constant 5 is not assignable (not an lvalue). Only mutable values (lvalues) can have the ++operator operate on them. Constants are necessarily immutable rvalues.
Doesn't the left side get evaluated first then the result is assigned to the variable?
++ is a version of += so I can see why that might fail in SWIFT.
It will fail in C, C++, Java, JavaScript, or any other language I know of that has a ++ operator that means "increment".
The left side is let d. It's on the left side of the assignment operator =. The right side is 5++. In order to assign a value, the right side must be evaluated, otherwise there's no value that can be assigned. Since 5 is not an lvalue in and of itself, the expression 5++ is invalid, because ++ and -- can only operate on lvalues.
An rvalue is effectively constant (unchangeable), so it's logically impossible to change it. If it were logically possible to change it, then it would be classified as an lvalue, not an rvalue.