> On Jun 24, 2017, at 12:25 PM, Djura Retired Hunter 
> <retired.hunter.dj...@gmail.com> wrote:
> 
> I didn't understand your example at all. Care to elaborate?
> 
> Elviro
> 
>> Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker <dary...@mac.com 
>> <mailto:dary...@mac.com>> ha scritto:
>> 
>> 
>>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> It's probably late to just casually add a couple of cents to a discussion 
>>> that has been going for so long, but it seems to me that from a user 
>>> standpoint, that uses types to structure their programs and define logic 
>>> and relationships, isomorphic types should be considered the same by the 
>>> compiler. The added burden of distinguishing between, to say, a function 
>>> that takes 2 arguments and one that takes a single tuple of two arguments 
>>> doesn't seem useful at all, at least from the standpoint of the types 
>>> involves. All the rest, like named parameters or tuple labels, are just 
>>> really about style and convenience, but isomorphic types, while not 
>>> strictly equal (the very concept of "equal" is in fact a huge deal in 
>>> abstract mathematics) are for all means "equivalent" for the world-modeler.
>> 
>> Doesn’t seem useful?…
>> 
>> let myFunc: (MyTypeAlias) -> Int = /* … */
>> 
>> Does the function pointer have a single parameter? Or does it trigger 
>> Super-Secret Tuple-Destructing mode and actually indicate two parameters? My 
>> secret unknown single type should always be a single type, no matter what 
>> kind of type it is.

(A, B, C)  ((A, B), C)  (A, (B, C))

You’re saying partitions aren’t important. I’m saying that they are. Even 
though the second two tuples above are implemented like the first, I wouldn’t 
want them to be indistinguishable from an user’s standpoint. I wouldn’t want my 
two-argument functions magically become a three-argument one due to 
implementation details.

My previous example will stay an one-argument function for any non-tuple type 
behind the alias. But if it’s a tuple type, my assumption breaks because your 
rules would ban tuples from being first-class types.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to