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
<[email protected] <mailto:[email protected]>>:
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
