"bounded" sounds good to me, but I don't know if "optional" is a good choice as it could be highlighted as a reserved keyword:
https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design - Luis On Fri, Apr 29, 2016 at 5:08 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > From my point of view, > truncate -> bounded > lenient -> keep "lenient:" ? "requested:" ? "optional:"? > > On 29.04.2016 17:46, Thorsten Seitz wrote: > >> Some alternatives to 'safe:' >> >> existing: >> bounded: >> valid: >> >> -Thorsten >> >> Am 29.04.2016 um 00:20 schrieb Luis Henrique B. Sousa via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> Thanks Vladimir, your considerations and suggestions are totally valid, >>> I'm going to change the document accordingly. >>> Also as a non-native English speaker I think that other words could fit >>> better, such as 'tolerant' or 'permissive' -- but I dunno if they would >>> look great as a label. We will come up with the right keyword for it. >>> >>> In relation to bad code, it could be a valid argument if my initial >>> proposal was under discussion instead, where the default 'fail fast' >>> behaviour would be "camouflaged" and bugs would be more difficult to >>> catch. In this new proposal we have such features explicitly defined, >>> where the user will be familiar with what it does and what results to >>> expect for. I don't see a way that it could drive to bad written code. >>> >>> - Luis >>> >>> On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S <sva...@gmail.com >>> <mailto:sva...@gmail.com>> wrote: >>> >>> I support this proposal. Probably we all should select the best >>> labels (truncate/lenient or other). As not native English speaker, I >>> don't feel like 'lenient' is well-known word or often-used word in >>> software development. But all this just a details we need to discuss. >>> >>> What I think could be improved - is a motivation section. IMO the >>> main purpose of proposed features is not to "eliminate the need for >>> validations, reduce the number of fatal errors in runtime" but to >>> allow us to have more clean code when *such validations just don't >>> required*, when we just *don't care* about details. >>> I.e. in situations, when we'll use [max(-1, a.startIndex) ..< min(5, >>> a.endIndex)] and bounds checking manually to have the same result as >>> in proposed subscripts. >>> >>> I.e. it is just a very handy addition to standard methods for >>> collections, just like we can get first element by index but we have >>> handy property '.first' for this purpose. Btw, it does not raise >>> error, but returns T?. I think you can add notes regarding analogues >>> with .first / .last properties(and probably with other) in proposal >>> text. >>> >>> Someone can argue, that by using these subscripts, coders can write >>> 'bad' code - but I can't accept such an argument - 'bad' coders >>> already can write 'bad' code with other features of Swift and at the >>> end they can implement these subscripts in their project and write >>> 'bad' code. Should we stop to introduce handy and explicit feature >>> for 'good' coders because of this? >>> >>> On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution >>> wrote: >>> >>> As we have discussed throughout this thread, the initial >>> proposal was >>> modified to include alternative subscript methods instead of >>> modifying the >>> default operator/subscript behaviour. >>> The first draft is >>> here: >>> >>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md >>> >>> I've also put this as a gist so that you can leave comments with >>> respect to >>> the proposal document itself. Any suggestion or help is very >>> welcome. >>> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8 >>> >>> Regards, >>> >>> - Luis >>> >>> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa >>> <lshso...@gmail.com <mailto:lshso...@gmail.com> >>> <mailto:lshso...@gmail.com <mailto:lshso...@gmail.com>>> wrote: >>> >>> This proposal seeks to provide a safer ..< (aka half-open >>> range >>> operator) in order to avoid **Array index out of range** >>> errors in >>> execution time. >>> >>> Here is my first draft for this proposal: >>> >>> >>> https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md >>> >>> In short, doing that in Swift causes a runtime error: >>> >>> leta =[1,2,3] >>> letb =a[0..<5] >>> print(b) >>> >>> > Error running code: >>> > fatal error: Array index out of range >>> >>> The proposed solution is to slice the array returning all >>> elements that >>> are below the half-open operator, even though the number of >>> elements is >>> lesser than the ending of the half-open operator. So the >>> example above >>> would return [1,2,3]. >>> We can see this very behaviour in other languages, such as >>> Python and >>> Ruby as shown in the proposal draft. >>> >>> This would eliminate the need for verifications on the array >>> size >>> before slicing it -- and consequently runtime errors in cases >>> when the >>> programmer didn't. >>> >>> Viewing that it is my very first proposal, any feedback will >>> be helpful. >>> >>> Thanks! >>> >>> Luis Henrique Borges >>> @luishborges >>> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto: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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution