[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu]

What scenario are you referring to?


On Sun, Mar 26, 2017 at 03:38 <jaden.geller at gmail.com> wrote:

> This will not always work, particularly when both symbols already have an
> identical type.
>
> On Mar 26, 2017, at 1:29 AM, Xiaodi Wu <xiaodi.wu at gmail.com> 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 <
> swift-evolution at swift.org> wrote:
>
>
>
> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution <
> swift-evolution at swift.org> 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 <xiaodi.wu at gmail.com>
> To: Carl Brown1/US/IBM at IBM
> Cc: Drew Crawford <drew at sealedabstract.com>, Jonathan Hull <jhull at gbis.com>,
> swift-evolution <swift-evolution at swift.org>
> 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 <*Carl.Brown1 at ibm.com*
> <Carl.Brown1 at ibm.com>> 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 <*Carl.Brown1 at ibm.com*
>    <Carl.Brown1 at ibm.com>> wrote: > Maybe this is the core
>
>    From: Xiaodi Wu <*xiaodi.wu at gmail.com* <xiaodi.wu at gmail.com>>
>    To: Carl Brown1/US/IBM at IBM
>    Cc: Drew Crawford <*drew at sealedabstract.com* <drew at sealedabstract.com>>,
>    Jonathan Hull <*jhull at gbis.com* <jhull at gbis.com>>, swift-evolution <
>    *swift-evolution at swift.org* <swift-evolution at swift.org>>
>    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 <*Carl.Brown1 at ibm.com*
>    <Carl.Brown1 at ibm.com>> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170326/4f7f9cf3/attachment.html>