Thoughts on SWIFT type inferrence

Discussion in 'iOS Programming' started by AdonisSMU, Jul 1, 2014.

  1. AdonisSMU macrumors 603

    Joined:
    Oct 23, 2010
    #1
    I like the idea of this feature but I think I prefer clarity. I know having options is nice but sometimes it can actually make a mess of things....
     
  2. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #2
    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.
     
  3. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #3
    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.
     
  4. AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #4
    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....

    ----------

    This is what I was thinking but I wanted to hear other opinions...
     
  5. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #5
    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...
     
  6. AdonisSMU, Jul 2, 2014
    Last edited: Jul 2, 2014

    AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #6
    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.
     
  7. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #7
    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.
     
  8. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #8
    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.
     
  9. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #9
    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:

    Code:
    let d = .5
    ?
     
  10. AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #10
    thats a bug...
     
  11. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #11
    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.
     
  12. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #12
    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.5
    while this is illegal:

    Code:
    let d = .5
     
  13. AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #13


    You're not making sense?
     
  14. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
  15. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #15
    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.
     
  16. AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #16
    I know I tried it. Thats not intuitive...
     
  17. MattInOz macrumors 68030

    MattInOz

    Joined:
    Jan 19, 2006
    Location:
    Sydney
    #17
    In a lot of technical areas ".5" would not be acceptable for "0.5".

    It might seem redundant seeing code is rarely printed but still it's a convention a lot of people in technical fields would be use to.
     
  18. AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #18
    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.
     
  19. MattInOz macrumors 68030

    MattInOz

    Joined:
    Jan 19, 2006
    Location:
    Sydney
    #19
    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.
     
  20. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #20
    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.
     
  21. AdonisSMU thread starter macrumors 603

    Joined:
    Oct 23, 2010
    #21
    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.
     
  22. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #22
    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.
     

Share This Page