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? Félix > Le 1 juin 2016 à 22:35:21, L Mihalkovic via swift-evolution > <swift-evolution@swift.org> a écrit : > > >> On Jun 1, 2016, at 11:20 PM, Vladimir.S <sva...@gmail.com >> <mailto:sva...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
