Sorry, it's been a while but I don't understand your reply. As far as I can tell, nothing has changed since June: the revised proposal continues to propose an API that is not protocol-based, and the alternative continues to propose additions to RangeExpression that do not make sense, as partial ranges do not have both upper and lower bounds.
As I wrote in June, _even if clamping is determined to be a suitable addition to the standard library_, your revision appears not to address the core team feedback. I suggested one way in which you could revise your proposal to address that issue--namely, a `clamping` requirement on RangeExpression. However, I do not see where you have addressed this feedback. What am I missing? On Wed, Jul 19, 2017 at 22:48 Nicholas Maccharoli <nmacchar...@gmail.com> wrote: > Xiaodi, > > Sorry for the delay and thanks for replying! > > Well, as to if this meets the standard thats something more subjective > than objective so > after hearing a few opinions (hopefully differing) the community could > piece together > a cleaner image of if this is a good idea or not. > > From the previous feedback on the mailing list there were people in favor > and Ben from the > core swift team gave some feedback here saying: > > https://github.com/apple/swift-evolution/pull/718 > > The core team reviewed this proposal and are returning the proposal for >> revision. This is a welcome proposal in principal, but should be revised to >> account for the recent addition of the RangeExpression protocol, in >> order to allow for clamping over different kinds of range expression. > > > > So since the proposal is being "Returned for revisions" I wanted to > propose those revisions here: > > https://github.com/apple/swift-evolution/pull/723 > > - Nick > > > > > On Wed, Jun 28, 2017 at 1:13 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> RangeExpression is a protocol for all ranges, including partial and >> unbounded ranges. It would not make sense for such a protocol to have an >> upper bound or a lower bound. >> >> The way in which your proposal could dovetail with RangeExpression is for >> it to add a requirement to that protocol named `clamping(_:)`. Each type of >> range (_, closed, countable, countable closed, partial from, partial up to, >> etc.) would then implement that requirement. Then, implementations of >> `clamped(to:)` could call `clamping(_:)`. Although, at that point, it would >> be an open question whether having both clamped(to:) and clamping(_:) would >> be useful. I would be inclined to think that at most one of these is >> necessary, and only the latter is compatible with a protocol-based approach. >> >> I remain unconvinced, however, that this API meets the very high bar for >> standard library inclusion. >> >> >> On Tue, Jun 27, 2017 at 20:57 Nicholas Maccharoli via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Swift Evolution, >>> >>> I want to thank the community for the previous feedback for SE-0177 >>> and also address the issue of the proposal being sent back for >>> revisions. >>> >>> The current status being "Returned for revisions" reflects the detailed >>> design section being incomplete and not working against the latest Swift >>> 4 >>> snapshot. >>> >>> Another reason mentioned by Ben Cohen was that the proposal did not take >>> advantage of `RangeExpression` and take advantage of a generic >>> implementation. >>> >>> This has been added in the "Alternatives Considered" section in the pull >>> request that >>> is open now but I personally favor the generic approach despite the >>> added cost of extending `RangeExpression` enough to make the implementation >>> possible. >>> >>> In short, at this time `RangeExpression` is lacking functionality to >>> implement `clamp(to:)` >>> in a generic fashion so if the community is in favor of extending >>> `RangeExpression` I am >>> more than happy to go with a generic implementation rather than the >>> current concrete >>> implementation that is in the proposal pull request now. >>> >>> I have tried to address these issues and expand the proposal in this >>> pull request here: >>> >>> https://github.com/apple/swift-evolution/pull/723 >>> >>> Thank you all so much for the feedback and support, I look forward to >>> exploring where >>> we can go with this proposal and making Swift 4 the best release yet. >>> >>> Forever your Swift Evolution buddy, >>> >>> - Nick >>> >>> >>> _______________________________________________ >>> 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
