[swift-evolution] Ad hoc enums / options

[Félix Cloutier]

You talked about the "compiler's point of view" and said about tuples that "the compiler never thinks that they are the same type". At which level is that true if we're not talking about the internal workings of the compiler?

There is consensus that Swift does not currently allow enums to be defined like tuples. Of course this is not how things work currently; we wouldn't be having a proposal otherwise! I don't see what this adds to the conversation. You could use that argument against any idea of future development.

Félix

> Le 1 juin 2016 à 23:25:10, L Mihalkovic <laurent.mihalkovic at gmail.com> a écrit :
> 
> 
>> On Jun 2, 2016, at 8:04 AM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>> 
>> I was once relying on the state of things to judge the validity of some access modifier claims and I was rebuked on the grounds that proposals should be evaluated based on their merits, not on implementation details.
>> 
>> And as far as implementation details go, this doesn't match what I understand of tuples. Looking at SIL, tuple types from different declarations appear just as identical as they do in source code. In fact, the output is exactly the same even when using a tuple typealias. Do you have an experiment or compiler code that would support your claims?
> 
> I do not understand your question as it is formulated. What I described is the external behavior. I did not make any reference to the internal structure of the C++ that has managed to make heavy reuse of certain concepts across the whole type system, so indeed part of the differences we perceive at the language level do not exist identically at the implementation level. A fact remains, the language is defined by its grammar… and the grammar chose to expose certain concepts through what we know as struct, class, enum, tuple. Swift could have decided to offer a single Ω data type that would have displayed the behavior of all it current user defined types depending on where it was used. but that would not be swift, right?!
> 
>> Félix
>> 
>>> Le 1 juin 2016 à 22:35:21, L Mihalkovic via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> 
>>>> On Jun 1, 2016, at 11:20 PM, Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>> wrote:
>>>> 
>>>> OK, I understand most of your points and feel the same regarding the proposed feature... but:
>>>> 
>>>> > .. the compiler does not like when we define the same thing twice, and thse short form amount to doing what he does not let us do. ..
>>>> > .. if we use an annotation that lets it know that "it is not a mistake..
>>>> > I really dont want to write that enum myself, even though I am using the
>>>> > same abbreviation twice". Otherwise, the compiler would let us know that
>>>> > the second time could be a mistake because there is already something
>>>> > with the same name...
>>>> 
>>>> I just wanted to understand how such enums are different than tuples in meaning of "I don't want to write the struct myself", "Yes, I'm using the same tuple twice", "Compiler will let us know that we used the same tuple again and probably mistake as has already the same". (Not about differences in implementation/representation on compiler level, but on level of one who is writting the code)
>>>> 
>>>> Should we use the same arguments to propose the special annotation when we have the same tuple more than once? No. So I believe there should be no such limitation and special annotation for proposed enums.
>>>> 
>>> 
>>> I am not sure the parallel can be made. A tuple is characterized by its structure, BUT the scope of its use is the VARIABLE where it is being used (I am simplifying by only referring to var/let cases). So from the compiler’s point of view, there is not a giant Tuples hash table where it can look for a given tuple definition based on its intrinsic name. So even if you repeat the same tuple definition every other line in your source code, the compiler never thinks that they are the same type because they ARE NOT the same. Each one is a different variable (the compiler would complain that the variable is defined multiple times though). To simplify the model, you could almost think that a tuple is a degenerate struct that is internally given the name of its usage site. It is not quite true but it is a close-enough approximation of what it really is.
>>> 
>>> The only rational for allowing a @I_know_what_I_am_doing_so_please_dont_complain annotation is to allow (and I am not saying it should be allowed)
>>> 
>>> 
>>> func scaleAndCropLargeImage(
>>>     image: UIImage,
>>>     toSize size: CGSize,
>>>     operation: (.Fit | .Fill) = .Fit
>>>     ) -> UIImage {
>>>   whoCaresThereIsReallyASingleTypeOfImagesAnyhow()
>>> }
>>> 
>>> func scaleAndCropSmallImage(
>>>     image: UIImage,
>>>     toSize size: CGSize,
>>>     operation: (.Fit | .Fill) = .Fit
>>>     ) -> UIImage {
>>>   whoCaresThereIsReallyASingleTypeOfImagesAnyhow()
>>> }
>>> 
>>> 
>>> private 
>>> func whoCaresThereIsReallyASingleTypeOfImagesAnyhow(
>>>     image: UIImage,
>>>     toSize size: CGSize,
>>>     operation: (.Fit | .Fill) = .Fit
>>>     ) -> UIImage {
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/459e67fb/attachment.html>