> On Jan 7, 2017, at 22:51, David Sweeris <daveswee...@mac.com> wrote:
> A really convenient way to pass around multiple values without having to
> bother with a formal struct.
That's actually a big part of my concern.
The people on this list are, I'm certain, among the top programmers working.
I'm more worried about what happens when average (which IME means barely
competent) developers get going with this. I suspect nobody will ever declare
a struct again. Type declarations are valuable - they are an opportunity to
express intent. OTOH, a pair of ints is a pair of ints and if all pairs of
ints are type compatible then opportunities for catching errors drop if
developers start favoring anonymous tuples over former structs.
> On Jan 7, 2017, at 23:37, Derrick Ho <wh1pch...@gmail.com> wrote:
>
> I think pattern matching is the most compelling reason to keep tuples.
>
> If they were gone, how would we replace the following?
>
> switch (a, b) {
> case (value1, value2):
> case (value3, value4):
> }
I really have to ask. What do you use this for? In general iPhone application
programming I have never wanted or needed to do that. I do some AudioUnits as
well. Still never needed it.
Since taking on rescuing a few 2.3 projects on behalf of their highly
dissatisfied clients (I do this for all languages - not meant to be a Swift
ding), I have found an astonishing abundance of switch statements that should
have been handled by subclassing and polymorphism.
The only time I ever find a use for a switch statement is in a parser handling
wild input.
Regardless, I would extend it to formal structs I think
switch StructName(a, b) {
case (value1, value2):
case (value3, value4):
}
> On Jan 8, 2017, at 05:46, Rod Brown <rodney.bro...@icloud.com> wrote:
>
> Apart from your seeming distain for Swift
I tried very hard to keep from expressing anything like that in my proposal.
Did I fail? How?
Language designs tend to encourage some behaviors and discourage others. The
goal should be to encourage good practices and discourage bad ones. I am
basing quite a lot of my opinion on the code being written by other developers
that I am then asked to come in and work on. Second generation code. Is it
aging well? Why or why not? Anonymous types everywhere isn't really making
things safer. An anonymous pair of ints is an anonymous pair of ints. You
might as well return an Array (and adding fixed dimensions as part of the
immutable array type would solve this just as well). eg [T][4] or some such
syntax. So mostly I'm seeing arguments to keep the syntax because the syntax
is the syntax because that's what the type is so that is the syntax of the type.
> The following two are collection types you’ve arbitrarily attacked for no
> reason. There are plenty of examples where each of these makes sense and is
> relevant within the language:
> 3. Arrays - Lists of items.
> 4. Dictionarys - Key value pair collections.
I did not attack them. I like them. I would generally use them instead of
tuples. That's how Cocoa largely works now. I used them as comparisons.
> Tuples themselves are actually a major part of how the language is built
> under the covers, and removing them for no reason is part of taking the guts
> out of Swift, for no reason.
I don't care what it looks like under the covers. I am talking about what it
looks like to the developer. Seems a bit "Tower of Babel-ish" in some areas.
The goal was to point that out and see if the language could be simplified.
> On Jan 7, 2017, at 22:51, David Sweeris <daveswee...@mac.com> wrote:
>
>
>
>> On Jan 7, 2017, at 19:34, Freak Show <freaksho...@mac.com> wrote:
>>
>> I think you're missing the forrest for the trees here.'
>>
>> Let me ask this: if you remove tuples from the language - what have you
>> lost - really? You can still say everything you could before.
>
> A really convenient way to pass around multiple values without having to
> bother with a formal struct.
>
> - Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
