Yes @Matthew, I did; my very first draft sought to change the default subscript method. However, there were some opinions against overriding the default *fail fast* behaviour as it could result in more bugs and in an overload to debug. It wasn't set in stone, so I think it's something that could be discussed if this proposal goes to review.
- Luis On Fri, May 6, 2016 at 5:22 PM, Matthew Johnson <matt...@anandabits.com> wrote: > Did you consider making the safer, optional overload the "default" and > just omit the label? > > Sent from my iPad > > On May 6, 2016, at 10:23 AM, Luis Henrique B. Sousa via swift-evolution < > swift-evolution@swift.org> wrote: > > "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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution