> * What is your evaluation of the proposal? -1. I prefer the MemoryLayout struct approach that Dave Abrahams has suggested. The proposed names retain the the disadvantage of several top level names and introduce a new disadvantage that they are not directly related to familiar terms of art (sizeof from C, etc).
> * Is the problem being addressed significant enough to warrant a change > to Swift? I don’t think it is a critical change given the current names are related to terms of art. If we are going to make a change I think it is better to reduce the number of top level names and make the relationship of them clear by making them members of a type. > * Does this proposal fit well with the feel and direction of Swift? It fits the Swift 3 directive to do any breaking change bike shedding now. However, the overall direction of Swift is away from top level functions without a compelling reason that a top level function is necessary. I don’t think these cases are compelling. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? They break the tie to familiar naming from other languages. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Participated quite a bit in the initial discussion and read the final proposal. > > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris Lattner > Review Manager > > _______________________________________________ > 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
