The one line file named “a.swift” with content “print(42)”, and the shell command “swift a.swift” responds with the output “42” on a line by itself.
The man page for Swift was written by the marketing department and gave no clue to the necessary file extension.
My opinion of Swift increased, however, for making at least some simple things simple, even guessable.
Even easier an REPL: Shell command “swift”; type “print(42)”; see “42”.
Even strict languages can do this and many do not.
+10
Swift has fallen for the “terminal semi-colons are unnecessary” fad (in my opinion).
−4
The ‘string literal’ “"Z\(3)πoo"” produces “Z3πoo”.
Quine’s quasi quotes, very good.
+3
In their introduction to types it is clear that they have achieved at least some of the slick notation of the ML languages, at least regarding tuples.
We shall see.
+6
I have a philosophical issue with the notion of “named type”.
It is wrong for the same reason that the notion “named integer” is wrong.
Whether it has a name is no more a property of a type than it is a property of an integer.
The property “named in some library” might be of passing interest.
+0
In Swift, a function takes a tuple and returns a tuple.
This might be superior to ML languages, but only if there are 1-tuples and 0-tuples.
Currying is nice and elegant, but ultimately unnecessary.
I think that they presume the existence of n-tuples for all integers ≥ 0.
There are 1-tuples but no Swift program produces any.
No sweat.
The notation that you might expect to produce the 1-tuple with 3, “(3)”, has already been assigned to denote 3.
The “n” in “n-tuple” is always manifest in the source and the funny rule seems notationally strategic and harmless.
Very much like ML languages.
+2
I have a bad feeling about “Protocol Composition Type”.
This is presumably the ‘principle discussion’ and it relies on ‘protocol’ which has not been discussed except to identify a keyword.
I am not aligned with class and inheritance notions of most modern languages, not even OCaml.
But I need to see farther to make a judgement.
+0
I hold “Meta Type” in abeyance for now.
The assignment operator is described poorly.
I suspect the semantics are good but they need a ‘pattern’ syntactic category to explain things clearly.
here?
−0
quote “The is operator checks at runtime whether the expression can be cast to the specified type. It returns true if the expression can be cast to the specified type; otherwise, it returns false.” This is the wrong time to learn that not all types are known at compile time.
Statements beginning “let” & “var” have not been introduced but they already appear in examples.
You cannot assign to x from “let x = 8” but you can from “var x = 8”.
At least they provide the more fundamental construct on an equal syntactic footing rather than C’s construct where “const int x = 4” is parasitic on the variable x which is in turn parasitic on integers.
In general I think the casting operators are too much syntax for too little function.
+1 (for now)
I needed Google to learn where to find sqrt.
The swift program needs the statement “import Foundation”.
Here is a curious outcropping of technology.
−1 (documentation should have conceptual (as well as real) up-pointers)
The section: “For-In Statement” refers to the “GeneratorType protocol” without a link.
More links or an index would help.
The construct seems to support fairly general co-routines.
+2
There are many constructs described that could mostly be defined in terms of previous constructs. This would be good pedagogy. There are several statements just for old time sake, with little current justification. The good news is that they can be mostly defined away. Those trying to reason about security and type safety would benefit from assurances that these features added only convenience but no power.
Regarding the section titled “In-Out Parameters”, I prefer the Algol68 solution to this problem but at least the call site must visibly warn of write access to the variable.
−1
Where in OCaml you might say “let e = 2 in print_int e;” and not disturb the meaning or value of some outer-scope variable named e, you can say in Swift: “do {let e = 3; print(e);}”.
I actually prefer the Swift way because parens savvy editors grok the latter.
The “do” is awkward but short.
Alas there is nothing like OCaml’s “let x = f(7) in x+x” which yields a value and in which x does not occur freely.
Even clang has “({int x = f(7); x+x;})”.
−1
OCaml provides the identity function as “let i x = x;”.
In Swift the expression “let i = {$0}” provokes the compiler to say:“repl.swift:1:9: error: unable to infer closure return type in current context”.
There may be compensating advantages.
−2