Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md What is your evaluation of the proposal?
-1 The proposal puts all the emphasis on the programmer. It is better for the compiler to decide if something is to be inclined both across modules and within modules. If something is made public then it should be fixed for a given major version number. No need for extra annotation. A module system that allows versioning is a better solution. Is the problem being addressed significant enough to warrant a change to Swift? Yes significant but wrong solution Does this proposal fit well with the feel and direction of Swift? No, cluttering up declarations is completely against the clarity of Swift. For example who other than people on this group will understand @inline(never) @inlinable. If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Yes C and C++ and found the equivalent of these annotations problematic. In Java they eliminated all this and let the compiler do the work. In practice this works much better. Perhaps the compiler should publish the SIL or LLVM for all public functions. Analogous to Java’s class files. This sort of system works really will, much better than C and C++. How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Followed the discussions and read the proposal. The proposal doesn’t seem to encompass all the discussions. It would be nice if the proposal had a much more extensive summary of alternatives suggested. -- Howard. > On 20 Dec 2017, at 7:19 pm, Ted Kremenek via swift-evolution > <swift-evolution@swift.org> wrote: > > 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? > > Is the problem being addressed significant enough to warrant a change to > Swift? > > Does this proposal fit well with the feel and direction of Swift? > > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? > > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
