This will not always work, particularly when both symbols already have an identical type.
> On Mar 26, 2017, at 1:29 AM, Xiaodi Wu <[email protected]> wrote: > > I think this is where some special behavior in the migrator is called for. > Where an overload ambiguity appears, it will need to insert an "as T" to > disambiguate. > > Carl's standard can be strictly met by a migrator that compares all uses of > private facilities under the new and old meaning of private, ensuring that no > uses emerge or disappear after rollback. >> On Sun, Mar 26, 2017 at 03:23 Jaden Geller via swift-evolution >> <[email protected]> wrote: >> >> >> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution >> <[email protected]> wrote: >> >>>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution >>>> <[email protected]> wrote: >>>> Yes, it would change my opinion of it. I wouldn't become a strong >>>> supporter because I don't see any value in it, but a rigorous proof that >>>> this proposal could not possibly introduce regressions to any existing >>>> codebases would change my opinion from "strongly against" to "doesn't >>>> matter to me, I'll stop arguing against it and go get my real work done". >>>> >>> Speaking just for myself, this was a key part of why I was attracted to >>> this proposal: it seemed to me to be extremely unlikely to cause >>> regressions in behavior. Even without any special behavior in the >>> migrator, code will mostly work exactly as before: things that would have >>> been invalid before will become valid, but not the other way around. >> >> What about overloads that become ambiguous? I admit this is a fringe case. >> >>> The exception is that old-private declarations from scopes in the same file >>> can now be found by lookups in different scopes (but still only within the >>> same file). It should be quite straightforward for the migrator to detect >>> when this has happened and report it as something for the programmer to >>> look at. The proposal causes a small regression in functionality, in that >>> there's no longer any way to protect scopes from accesses within the file, >>> but (1) it's okay for Swift to be opinionated about file size and (2) it >>> seems to me that a workable sub-module proposal should solve that more >>> elegantly while simultaneously addressing the concerns of the people who >>> dislike acknowledging the existence of files. >>> >>> John. >>>> -Carl >>>> >>>> <graycol.gif>Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your >>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 >>>> <Carl.Br >>>> >>>> From: Xiaodi Wu <[email protected]> >>>> To: Carl Brown1/US/IBM@IBM >>>> Cc: Drew Crawford <[email protected]>, Jonathan Hull >>>> <[email protected]>, swift-evolution <[email protected]> >>>> Date: 03/25/2017 12:33 AM >>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels >>>> >>>> >>>> >>>> >>>> Would it change your opinion on the proposal? >>>> >>>> >>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <[email protected]> wrote: >>>> I would very much like to see your proof that the resultant code is >>>> unchanged in an arbitrary codebase. >>>> >>>> -Carl >>>> >>>> <graycol.gif>Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at >>>> 11:55 PM, Carl Brown1 <[email protected]> wrote: > Maybe this is the core >>>> >>>> From: Xiaodi Wu <[email protected]> >>>> To: Carl Brown1/US/IBM@IBM >>>> Cc: Drew Crawford <[email protected]>, Jonathan Hull >>>> <[email protected]>, swift-evolution <[email protected]> >>>> Date: 03/25/2017 12:01 AM >>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels >>>> >>>> >>>> >>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <[email protected]> wrote: >>>> My point is that, in rolling back the specific portion of SE-0025, >>>> case-sensitive find-and-replace will be the trickiest thing in most >>>> codebases, save those that result in invalid redeclarations. The behavior >>>> of the resultant code is, unless I'm mistaken, provably unchanged. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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
