> On 6 Jan 2016, at 18:30, Don Wills via swift-users <swift-users@swift.org>
> wrote:
>
> Points well taken.
>
>> On Jan 6, 2016, at 11:02 AM, Jens Alfke <j...@mooseyard.com> wrote:
>>
>>
>
> I didn't want to post a tome about String, but here's a basic list of
> features/methods missing in String:
>
> 1. The lack a Character type that are the constituent elements of a String
> 2. Missing methods (Java names used): valueOf, charAt, trim(), length(),
> getBytes(), toUpperCase(), toLowerCase()
> 3. The lack of the + operator for appending
> 4. The lack of a StringBuilder (Java again) class
In Swift, String is intended to be Unicode correct. This means that the concept
of “character” is actually quite complex. It’s impossible to define charAt and
length without doing a linear search through the string.
getBytes() in Java is a disaster, although the variants where you specify an
explicit character set are fine and for UTF8 and UTF16 have an explicit
equivalent in Swift e.g.
let foo = Array("föo".utf8) // Array of UInt8 [102, 195, 182, 111]
valueOf() is covered by string interpolation e.g.
let number = “\(myDoubleVariable)”
trim() and toWhateverCase() are missing but are discriminatory to non latin
alphabets.
The + operator does exist for strings and StringBuilder is unnecessary because
a var string can be mutated.
var foo = “gfds”
foo += “fgfd"
Oh look += works for strings too.
>
>
> The cost of !, ? and ?? everywhere in the language is a huge coding and
> maintenance inconvenience for the programmer error condition referencing a
> variable that contains the value null.
Actually, I think the optional syntax is great. It forces you to think about
and deal with the equivalent of null pointers. Or put it this way, if Java
programmers were forced to handle all the possible cases where they might have
a null pointer instead of sweeping it under the carpet as they do, the
maintenance overhead and inconvenience would be far worse than with Swift.
Swift provides compiler support for answering the question “could this value be
nil”. Java doesn’t, which probably explains why the logs of many large Java
systems frequently contain stack dumps from null pointer exceptions.
>
>
> The fact that you claim Ints are primitives and Loïc Lecrenier in an email
> three minutes prior writes "Swift does not have primitives, but I consider
> that a plus..." Which is it?
The concept of “primitive” has no meaning in Swift. In Swift, there are value
types and reference types and user defined types and “built in” types are of
equal rank. Clever compiler optimisation allows some types to compile down to
CPU native types, but that is an implementation detail.
>
> Swift doesn't have exceptions? What are the "throws" clause on funcs and the
> try and throw statements?
In Swift, you throw errors, not exceptions. The word exception is (more or
less) reserved for conditions that terminate the process.
There are no unchecked errors but then why would you not want to handle an
error condition if it occurs? Why would you not want to know that an API can
throw an error?
I think Java’s checked exceptions are fine, but it really should not be
possible to catch an unchecked exception.
>
>>> The lack of packages and/or namespaces is another giant gaping hole.
>>
>> I agree with this, but I think it’s something that’s going to be addressed
>> in the future (see the current work on the package manager.)
>>
>> —Jens
>
> I come from the perspective of 45 years of experience in dozens of
> programming languages. Swift seems to be trying to be everything to
> everybody - a bridge from Obj-C, functional, imperative, procedural,
> object-oriented with a somewhat Java and C-like syntax. I've seen this movie
> before - it was called PL/I and was the IBM answer to merging COBOL and
> FORTRAN. Survivors: COBOL and FORTRAN. It appears to me that Swift is
> today's PL/I.
Having programmed in it quite a bit (a statement that, with respect, I think
does not apply to you) I can tell you that it is a joy to use. I love the fact
that I can pick the programming paradigm that is best suited to the problem I
am trying to solve. Furthermore, it has the advantage of being the language of
choice for the most successful mobile platform in terms of actual money. Now
that the toolchain is open source, I can only see its sphere of influence
expanding.
>
> Don
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
