A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple +
annotations’ relevant to use in parameter lists. If you can restrict this
pseudo-type to the appropriate context, like we are heading towards with
disallowing ImplicityUnwrappedOptional in function signatures, why not
restrict certain type annotations to only occur in function signatures?
Effectively the presence of parameter annotations in a tuple make it a
‘splat-only tuple’.
From James F
On 2 Jul 2016, at 05:38, James Froggatt <james.froggatt@me.com> wrote:
On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:
On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> >>> wrote:
On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@gmail.com> wrote:
This functionality naturally falls out of any decent proposal for
variadic generics. I'd rather wait until we can re-add it in a principled
manner than stuff yet another @-prefixed special case into the language.
Fair point, but it seems this could stand as a lightweight complement to
generics. There seems to be a lack of support for the side of keeping what
functionality we already have in this area.
FWIW, I liked and used tuple splat before it was removed from the
language.
I thought about it, and I think a lightweight, limited form of tuple
application would probably be worth pursuing even before variadic generics
go into the language (especially since they are a low-priority item).
Perhaps someone could draft a proposal for Swift 3.1.
This is why I support keeping what existing semantics we can, rather
than stripping it all out only to reimplement it as soon as people realise
it's missing.
The distinction between (Int, Int) and ((Int, Int)) seems trivial.
A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple +
annotations’ relevant to use in parameter lists. If you can restrict this
pseudo-type to the appropriate context, like we are heading towards with
disallowing ImplicityUnwrappedOptional in function signatures, why not
restrict certain type annotations to only occur in function signatures?
Is it though? Couldn't the current confusing situation of tuple labels
in the type system be changed in the exact same way?
Tuple labels work the way you expect them to work: you can't assign an
`(a: 1, b: 2)` to a variable of type `(x: Int, y: Int)`. There is nothing
confusing about them, at least not in the same way that function types are.
This seems just the same problem as not being able to assign:
(a: Int, b: Int) -> ()
to a type of:
(x: Int, y: Int) -> ()
Functions and tuples are the only uses of labels in the type system I'm
aware of. The reasoning for one case seems likely to apply to the other.
There was a better argument for this sort of thing before the naming
guidelines. Swift 2 argument labels often described the semantic value of
their arguments. Now you have guidelines which assign non-descriptive
prepositional phrases as argument labels. It makes no sense to pull the
prepositional phase comprising the argument label (as opposed to the
argument name itself) into the type, since that phrase is meaningless
outside the context of the primary function name, but the current system
(and any based off it) would do just that.
So no, I don't think the reasoning for tuple labels applies to function
argument labels.
Sorry, I meant the reasoning for removing them from the type system. As
you said, there was a better argument. I'm observing that this may once
again be the case following this change.
I still think it would be a bit odd to have (e.g.) a rejuvenated tuple
splatter try to enforce the labels on whatever tuples you pass to it, since
those labels would necessarily be tied to a specific function's name,
rather than the meaning of the arguments themselves. Do you think there
would be too much room for programmer error if such a splatter necessarily
took in unlabeled tuples? (Right now any labeled tuple is interchangeable
with a non-labeled tuple with the same constituent types...)
My idea is that if we switch to using:
let functionType(a:b:) = add(_:_:)
then it make sense to have tuples match this syntax, to avoid having two
similar naming mechanisms with very different semantics:
let values(x:y:) = (1, 2)
Like a function's argument labels are rarely sensible out of context,
tuples are best passed around without considering their labels. For example:
let name: (first: String, last: String) = …
name.first //clear
func join(stringTuple: (String, String))
join(stringTuple: name) //is this allowed?
At this point (generally as soon as the tuple leaves the context of its
containing variable), the original parameter labels are meaningless.
Alternatively:
let name(first:last:): (String, String) = …
name.first //still clear
join(name) //clearly allowed, since the labels are not part of the type
With this, if I understand you properly, argument names wouldn't be
present in the type system to begin with, so calling the result of a
splatter would be predictable:
join(a: String, b: String)
let splatted: ((String, String)) -> () = splat(join) // or splat(
join(a:b:) )
splatted(name) // or splatted( name(first:last:) )
It doesn't help that this went through to the wrong thread, and the
quick email I sent to acknowledge this has fallen in a hole somewhere.
Or are tuples destined to become nothing more than a historical
artifact? If this is the case, then we might as well remove them now.
Tuples have many, many uses apart from modeling argument lists.
• lightweight structs
• loosely-typed structs
• …as structs
There is no particular reason Void must be modelled as the empty struct,
since any non-subclassable Type.self is likewise a singleton.
So there's nothing really making a compelling argument here.
What? You asked if tuples were going to become a historical artifact?
The answer is, "no, they aren't, because they have uses besides modeling
argument labels". Void as the empty tuple is irrelevant to the discussion.
I'm not sure how to interpret this, sorry.
Perhaps I misunderstood your original point. In that case, I apologize.
------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <
CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>
On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>> >>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org> wrote:
Hello Swift community,
The review of "SE-0111: Remove type system significance of function
argument labels" begins now and runs through July 4. The proposal is
available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the
review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to
answer
in your review:
* What is your evaluation of the proposal?
+1. I'm in agreement with others in this thread who say that the labels
are
parts of the *name* of the function, not parts of its *type*. If I
understand the other discussions regarding the evolution of Swift's
function arguments model, the similarity to tuples with labeled
components
is a historical artifact and now merely coincidental.
The analogy to Objective-C here is obvious, where you have selectors
instead of functions. The selector is the "name" of the "function" and it
contains all of the parts, not just the base name.
Swift function names to me are like German separable verbs. Even when
they're split across the sentence with multiple words in-between, the
prefix is still considered part of that verb, not a separate
word/concept.
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes.
* Does this proposal fit well with the feel and direction of Swift?
Yes. This feels like a natural follow-up to SE-0021, which allowed the
use
of argument names to differentiate between overloads with the same
argument
types at the same positions. To me, this is another admission that the
labels are part of the function's *name*.
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Aside from Objective-C mentioned above, the other languages I've used
that
have named/keyword arguments (like Python) are dynamic languages that
treat
the incoming argument list as a dictionary; in that case, the language
design is significantly different and I can't draw an analogy between
them.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal and loosely followed the discussion.
More information about the Swift evolution process is available at
https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,
-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org
https://lists.swift.org/mailman/listinfo/swift-evolution
------------- End Message -------------
From James F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution