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

[Carl Brown1]

First off, SE-0159 does not, in my opinion and  the opinions of many people
on this list, present a superior experience for the end user.  It removes a
feature that many people use and will create more confusion by rendering
many online tutorials and answered questions incorrect.

Furthermore, the assertion that there is a "knowable" amount of effort
required to "roll back" corelibs-foundation is laughable.  "Look, it
compiles" is nowhere near the level of rigor required for a code base that
has as much code depending on it as Foundation has. Remember that the
standard for corelibs-foundation is not even "it works." The standard is:
"behaves the same way on Linux that Foundation does on Darwin."  If
something is accessible on Linux but not on Darwin, that's a bug, and needs
to get fixed.  Testing, finding, and fixing the regressions the "roll back"
will cause is what constitutes the bulk of the effort, and that amount of
effort cannot possibly be accurately estimated.

-Carl




From:	Xiaodi Wu via swift-evolution <swift-evolution at swift.org>
To:	Drew Crawford <drew at sealedabstract.com>, Jonathan Hull
            <jhull at gbis.com>
Cc:	swift-evolution <swift-evolution at swift.org>
Date:	03/24/2017 10:48 PM
Subject:	Re: [swift-evolution] [Review] SE-0159: Fix Private Access
            Levels
Sent by:	swift-evolution-bounces at swift.org



As Chris has said in the past, the core team is willing to endure a
substantial amount of implementation pain to present a superior experience
for the end user. In any case, I expect that the work needed to roll back
SE-0025 in the core libraries will likely be comparable if not less than
the remaining ongoing work needed in the compiler to make SE-0025 work
fully. Certainly, hundreds of hours would not be required to roll back
corelibs-foundation alone. The exact effort required is knowable, too, as
one can fork and migrate all uses of private to fileprivate right now and
see how long it takes.
On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <
swift-evolution at swift.org> wrote:





  On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jhull at gbis.com) wrote:


        This is exactly the problem. Both for access controls and dispatch.


  How would you respond to clattner's position piece on this?  He disputes
  this point directly:

        Swift is another case of a hybrid model: its semantics provide
        predictability between obviously static (structs, enums, and global
        funcs) and obviously dynamic (classes, protocols, and closures)
        constructs.  A focus of Swift (like Java and Javascript) is to
        provide an apparently simple programming model.  However, Swift
        also intentionally "cheats" in its global design by mixing in a few
        tricks to make the dynamic parts of the language optimizable by a
        static compiler in many common cases...
        The upshot of this is that Swift isn’t squarely in either of the
        static or dynamic camps: it aims to provide a very predictable
        performance model (someone writing a bootloader or firmware can
        stick to using Swift structs and have a simple guarantee of no
        dynamic overhead or runtime dependence) while also providing an
        expressive and clean high level programming model - simplifying
        learning and the common case where programmers don’t care to count
        cycles.


        Is it?  Can you point to an instance where a member of the core
        team said they are aiming for “plenty of overlap”?


  See above


        Honestly, most of your examples could just be split into multiple
        files.


  Specific arguments were advanced in those examples that they cannot.  Can
  you refute them?


        You are conflating effort by the swift design and implementation
        community with your personal effort around migration.


  No, I am referencing a Swift at IBM developer who reported that


        the open-source version of Foundation still has a long way to go to
        get the level of quality of the existing Objective-C frameworks,
        and we already have enough work to do without having to go make a
        bunch of arbitrary changes and risk a bunch of regressions because
        someone doesn't like a keyword... Accepting this proposal would
        waste hundreds of person-hours of work...
  _______________________________________________
  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/20170324/0559db5a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/0559db5a/attachment-0001.gif>