Ohh... I get it. We are saying the same thing, just differently. You look at source code then SIL and see that the SIL form is the same, which you formulate as they are the same for the compiler. The same situation is what i refer to as unique: the compiler does not realize what you did.. It simply did the work many times, producing the same code over and over. I call this "each one is unique".
> On Jun 2, 2016, at 6:03 PM, Félix Cloutier <[email protected]> wrote: > > 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; To me the double negative translates to "of course the compiler currently allow enum to be defined like tuples". Am I understanding it correctly? If u want yo see how far the differences go, u may want to try to create tiny app with one enum then one with one tuple, then inspect the binaries. > 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. Could, but hopefully never actually would, right!? > > Félix > >>> Le 1 juin 2016 à 23:25:10, L Mihalkovic <[email protected]> a >>> écrit : >>> >>> >>> On Jun 2, 2016, at 8:04 AM, Félix Cloutier <[email protected]> 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 >>>>> <[email protected]> a écrit : >>>>> >>>>> >>>>> On Jun 1, 2016, at 11:20 PM, Vladimir.S <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
