Skip to content

Commit 6516e8a

Browse files
committed
spelling: you
Signed-off-by: Josh Soref <[email protected]>
1 parent 8fd3730 commit 6516e8a

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/archive/TuplesAsArguments.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Then we hit a snag: naming guidelines. We wanted argument labels to be something
1212

1313
As seen earlier in the thread, argument labels don't make for good tuple element labels. Especially with the Swift 3 guidelines, argument labels usually don't make sense without the context provided by the base name, and two methods that happen to share argument labels might not actually be very similar, while two methods that are duals of each other might have different argument labels due to, well, English (e.g. `add(to:)` vs. `remove(from:)`).
1414

15-
The real blow, however, came with that very first idea: that we could treat methods with different argument labels as simple overloads in type. This led to poor diagnostics where the compiler couldn't decide whether to believe the types or the argument labels, and might tell you you have the wrong argument labels rather than a type mismatch. For pretty much every Apple API, this was the wrong decision. On top of all that, it was really hard to refer to a method when you didn't want to call it. (Most methods with the same base name still have unique labels, so you don't need the types to disambiguate.)
15+
The real blow, however, came with that very first idea: that we could treat methods with different argument labels as simple overloads in type. This led to poor diagnostics where the compiler couldn't decide whether to believe the types or the argument labels, and might tell you have the wrong argument labels rather than a type mismatch. For pretty much every Apple API, this was the wrong decision. On top of all that, it was really hard to refer to a method when you didn't want to call it. (Most methods with the same base name still have unique labels, so you don't need the types to disambiguate.)
1616

1717
So we introduced the notion of "full names", which are the things you see written as `move(from:to:)` (and which are represented by DeclName in the compiler). Almost immediately diagnostics got better, testing optional protocol requirements got shorter, and a lot of compiler implementation got simpler.
1818

0 commit comments

Comments
 (0)