[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu]

On Mon, May 8, 2017 at 4:01 AM, André Videla <andre.videla at gmail.com> wrote:

> > Why do you feel this clever puzzle needs to be eliminated?
> I dont feel like it needs to be eliminated.
>
> > Do you have any evidence that this shows up in real-world code?
> No.
>
> > For instance, I have had to use the name `T` at one point, because I was
> modeling something where `t` means a totally different thing.
> Other programming language implement the "prime" notation for those cases.
> Capitalisation is not the only alternative. If you have four variables
> related to each others you'd have t, t', t'' and t''' . If you use capitals
> you would use t, T and TT? Tt? T1? the next ones are not very clear.
>

To be clear, I'm not talking about related variables. In that particular
use case, I was modeling a mathematical transformation with two unrelated
constants named `T` and `t`. The only suitable name for `T` is therefore
`T`, as it cannot be `t`. There are other physical and mathematical
constants that are always referred to by uppercase or lowercase Latin or
Greek letters, for example, where the letter with the opposite case refers
to a totally different constant. It is reasonable to permit these special
uses to capitalize as necessary for clarity.

> Consider also C interop issues.
> I have no idea of the complexity of such a task but there is already some
> identifiers transformations for Obj-C interop. Maybe this kind of
> transformation could work for C interop.
>
> > the same could not be enforced for CJK variable names and type names
> And emoji.
>
> > Robert has presented a clever puzzle, but it is confusing only because
> he has deliberately designed it to be a puzzle.
> You'd be surprised how many kids playing with Swift in playgrounds create
> intricate puzzles for themselves unintentionally.
>
>
> 2017-05-08 10:42 GMT+02:00 Xiaodi Wu <xiaodi.wu at gmail.com>:
>
>> On Mon, May 8, 2017 at 3:35 AM, André Videla <andre.videla at gmail.com>
>> wrote:
>>
>>> By the way, it seems that the only way to get rid of this clever puzzle
>>> is to enforce uppercase for the first letter of type identifiers and lower
>>> case for values identifiers.
>>>
>>
>> Why do you feel this clever puzzle needs to be eliminated? Do you have
>> any evidence that this shows up in real-world code? As I said before, my
>> analysis is that it will only be found in code if the writer is
>> intentionally trying to torture his or her reader, which is a fruitless
>> issue to prevent.
>>
>> The convention of using uppercase only for the first letter of types is
>> already well observed. However, there are legitimate reasons why someone
>> may choose to name a member with uppercase. For instance, I have had to use
>> the name `T` at one point, because I was modeling something where `t` means
>> a totally different thing. Mathematical constants tend to differ based on
>> case. Consider also C interop issues. Finally, this distinction becomes
>> meaningless in languages without case; the same could not be enforced for
>> CJK variable names and type names, for example. However, it is possible to
>> warn when a variable name shadows a type, and this could be useful. But,
>> before we go designing anything in this area, again, as I've already
>> written in this thread, there will already be many compiler warnings and
>> errors if someone makes this mistake unintentionally; Robert has presented
>> a clever puzzle, but it is confusing only because he has deliberately
>> designed it to be a puzzle.
>>
>>
>> 2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <
>>> swift-evolution at swift.org>:
>>>
>>>> I still have to disagree on that. Tuple patterns are not consistent in
>>>> Swift.
>>>>
>>>> Here is a small proof of my claim:
>>>>
>>>> enum Foo {
>>>>
>>>>     case a(b: Int)
>>>> }
>>>>
>>>> switch Foo.a(b: 10) {
>>>>
>>>> case .a(b: let x):
>>>>     print(x)
>>>> }
>>>>
>>>> let tuple = (x: 2, y:  20)
>>>>
>>>> switch tuple {
>>>>
>>>> case (x: let a, y: let b):
>>>>     print(a); print(b)
>>>> }
>>>>
>>>> (x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!
>>>>
>>>> Tuple destructuring only works using the shorthand pattern, which _can_
>>>> lead to all those puzzles from the discussion.
>>>> ------------------------------
>>>>
>>>> The shorthand form ‘Is good and beautiful’ (German proverb), but it can
>>>> do more harm than it should. Personally I would entirely ban the shorthand
>>>> version unless we’ve got a superior version of it without all these issues.
>>>> ------------------------------
>>>>
>>>> By the way not only tuples are affected by the mentioned puzzle:
>>>>
>>>> enum Foo {
>>>>
>>>>     case sum(x: Int, y: Int)
>>>> }
>>>>
>>>> switch Foo.sum(x: 3, y: 1) {
>>>>
>>>> case let .sum(x: Int, y: Double):
>>>>     print(Int + Double) // prints 4
>>>> }
>>>>
>>>>
>>>>
>>>> --
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>>
>>>> Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution (
>>>> swift-evolution at swift.org) schrieb:
>>>>
>>>> But, in any case, with respect to consistency with the rest of the
>>>> language, tuple patterns with labels are *supremely* consistent.
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170508/ce652a31/attachment.html>