On Wed, Dec 20, 2017 at 18:19 Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote:
> The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md > > Reviews are an important part of the Swift evolution process. All review > feedback should be sent to the swift-evolution mailing list at: > > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the > review manager. > > When replying, please try to keep the proposal link at the top of the > message: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md > ... > Reply text > ... > Other replies > > What goes into a review of a proposal? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. > > When reviewing a proposal, here are some questions to consider: > > - > > What is your evaluation of the proposal? > > I have been doing the unkosher thing of using these underscored attributes and would very much like to see these formalized. My one bikeshedding issue here is the name @abiPublic, which smells too much like fileprivate in my subjective opinion. A more concrete objection here is the very much non-ideal juxtaposition of two different access modifier terms in the "@abiPublic internal" spelling. It would seem to me that "@abi" would suffice instead. Indeed, the fact that it's an "interface" implies a certain level of visibility, which in my view is more precise than coopting the term "public"--that term in turn has an established meaning in Swift that, by construction, an "@abiPublic internal" method does not fulfill. > - Is the problem being addressed significant enough to warrant a > change to Swift? > > Yes, we need this. > - Does this proposal fit well with the feel and direction of Swift? > > Yes, with a caveat. It seems a little unfortunate that @inline(never) is spelled so differently from @inlinable. Probably too late to rename the former @noninlinable though. It'd be lovely though. > - If you have used other languages or libraries with a similar > feature, how do you feel that this proposal compares to those? > > Not really, no. > - How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > I have used the underscored feature already, and I have read the document. Thanks, > Ted Kremenek > Review Manager > > _______________________________________________ > 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
