New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conventionalizing stride semantics #184

Merged
merged 1 commit into from Mar 11, 2016

Conversation

Projects
None yet
3 participants
@erica
Collaborator

erica commented Mar 1, 2016

Swift offers two stride functions, stride(to:, by:) and stride(through:, by:). This proposal introduces a third style and renames the existing to and through styles.

@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner
Collaborator

lattner commented Mar 11, 2016

dabrahams added a commit that referenced this pull request Mar 11, 2016

Merge pull request #184 from erica/stride
Conventionalizing stride semantics

@dabrahams dabrahams merged commit 0bf155d into apple:master Mar 11, 2016

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Mar 11, 2016

Collaborator

On Mar 11, 2016, at 12:35 PM, Chris Lattner notifications@github.com wrote:

@gribozavr https://github.com/gribozavr @dabrahams https://github.com/dabrahams ?

Quite honestly, in its current state, this half of the split proposal did not have strong support
when brought up on list. I'd rather not waste the team's time pushing a proposal without legs.

The problem it would be fixing would probably be better addressed by stepping back and re-thinking
closed and open intervals, ranges, strides, etc. (I know this is problematic given the resources
and time available to address this.)

-- Erica, who has been filling notebook pages with scribbles trying to think
through what she really wants from progressions

Collaborator

erica commented Mar 11, 2016

On Mar 11, 2016, at 12:35 PM, Chris Lattner notifications@github.com wrote:

@gribozavr https://github.com/gribozavr @dabrahams https://github.com/dabrahams ?

Quite honestly, in its current state, this half of the split proposal did not have strong support
when brought up on list. I'd rather not waste the team's time pushing a proposal without legs.

The problem it would be fixing would probably be better addressed by stepping back and re-thinking
closed and open intervals, ranges, strides, etc. (I know this is problematic given the resources
and time available to address this.)

-- Erica, who has been filling notebook pages with scribbles trying to think
through what she really wants from progressions

@dabrahams

This comment has been minimized.

Show comment
Hide comment
@dabrahams

dabrahams Mar 11, 2016

Member

On Mar 11, 2016, at 1:41 PM, Erica Sadun notifications@github.com wrote:

On Mar 11, 2016, at 12:35 PM, Chris Lattner notifications@github.com wrote:

@gribozavr https://github.com/gribozavr @dabrahams https://github.com/dabrahams ?

Quite honestly, in its current state, this half of the split proposal did not have strong support
when brought up on list. I'd rather not waste the team's time pushing a proposal without legs.

The problem it would be fixing would probably be better addressed by stepping back and re-thinking
closed and open intervals, ranges, strides, etc. (I know this is problematic given the resources
and time available to address this.)

I am impressed that you are taking the long view! I was thinking the same thing (especially in light of the new indexing model) but there’s no justification for rejecting the proposals for review at this point… unless you’re asking to withdraw them.
I just merged both proposals, but if you give me the word I’ll revert those changes.

-Dave

Member

dabrahams commented Mar 11, 2016

On Mar 11, 2016, at 1:41 PM, Erica Sadun notifications@github.com wrote:

On Mar 11, 2016, at 12:35 PM, Chris Lattner notifications@github.com wrote:

@gribozavr https://github.com/gribozavr @dabrahams https://github.com/dabrahams ?

Quite honestly, in its current state, this half of the split proposal did not have strong support
when brought up on list. I'd rather not waste the team's time pushing a proposal without legs.

The problem it would be fixing would probably be better addressed by stepping back and re-thinking
closed and open intervals, ranges, strides, etc. (I know this is problematic given the resources
and time available to address this.)

I am impressed that you are taking the long view! I was thinking the same thing (especially in light of the new indexing model) but there’s no justification for rejecting the proposals for review at this point… unless you’re asking to withdraw them.
I just merged both proposals, but if you give me the word I’ll revert those changes.

-Dave

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Mar 11, 2016

Collaborator

On Mar 11, 2016, at 2:46 PM, Dave Abrahams notifications@github.com wrote:

On Mar 11, 2016, at 1:41 PM, Erica Sadun notifications@github.com wrote:

On Mar 11, 2016, at 12:35 PM, Chris Lattner notifications@github.com wrote:

@gribozavr https://github.com/gribozavr @dabrahams https://github.com/dabrahams ?

Quite honestly, in its current state, this half of the split proposal did not have strong support
when brought up on list. I'd rather not waste the team's time pushing a proposal without legs.

The problem it would be fixing would probably be better addressed by stepping back and re-thinking
closed and open intervals, ranges, strides, etc. (I know this is problematic given the resources
and time available to address this.)

I am impressed that you are taking the long view! I was thinking the same thing (especially in light of the new indexing model) but there’s no justification for rejecting the proposals for review at this point… unless you’re asking to withdraw them.
I just merged both proposals, but if you give me the word I’ll revert those changes.

-Dave

@gribozavr <https://github.com/gribozavr https://github.com/gribozavr> @dabrahams <https://github.com/dabrahams https://github.com/dabrahams>

I actually do stand behind this proposal. I just worry that I'm fighting the wrong battle.

The other proposal's issues are clear: the math is demonstrably bad, and there are a bunch of
ways you can fix that for the short term while waiting for a better system in the long term.

With this proposal, the main objection voiced by the community was this: the words I chose
did not reflect the semantics of open and closed ranges. And I think that's the wrong objection.

I believe my semantics reflect natural ways to express the end progressions. These are end scenarios
that you'd encounter in for-loops, while-loops, and repeat-until loops. I was easily able to find reasons
to use all three situations that reflect: "while less than", "while less than or equal to", and
"until greater than or equal to".

At the same time, there are multiple issues with the current stride/interval/range system. I don't
want to waste everyone's time bailing water instead of designing a better hull.

Let me know what you think I should do.

-- Erica

Collaborator

erica commented Mar 11, 2016

On Mar 11, 2016, at 2:46 PM, Dave Abrahams notifications@github.com wrote:

On Mar 11, 2016, at 1:41 PM, Erica Sadun notifications@github.com wrote:

On Mar 11, 2016, at 12:35 PM, Chris Lattner notifications@github.com wrote:

@gribozavr https://github.com/gribozavr @dabrahams https://github.com/dabrahams ?

Quite honestly, in its current state, this half of the split proposal did not have strong support
when brought up on list. I'd rather not waste the team's time pushing a proposal without legs.

The problem it would be fixing would probably be better addressed by stepping back and re-thinking
closed and open intervals, ranges, strides, etc. (I know this is problematic given the resources
and time available to address this.)

I am impressed that you are taking the long view! I was thinking the same thing (especially in light of the new indexing model) but there’s no justification for rejecting the proposals for review at this point… unless you’re asking to withdraw them.
I just merged both proposals, but if you give me the word I’ll revert those changes.

-Dave

@gribozavr <https://github.com/gribozavr https://github.com/gribozavr> @dabrahams <https://github.com/dabrahams https://github.com/dabrahams>

I actually do stand behind this proposal. I just worry that I'm fighting the wrong battle.

The other proposal's issues are clear: the math is demonstrably bad, and there are a bunch of
ways you can fix that for the short term while waiting for a better system in the long term.

With this proposal, the main objection voiced by the community was this: the words I chose
did not reflect the semantics of open and closed ranges. And I think that's the wrong objection.

I believe my semantics reflect natural ways to express the end progressions. These are end scenarios
that you'd encounter in for-loops, while-loops, and repeat-until loops. I was easily able to find reasons
to use all three situations that reflect: "while less than", "while less than or equal to", and
"until greater than or equal to".

At the same time, there are multiple issues with the current stride/interval/range system. I don't
want to waste everyone's time bailing water instead of designing a better hull.

Let me know what you think I should do.

-- Erica

@dabrahams

This comment has been minimized.

Show comment
Hide comment
@dabrahams

dabrahams Mar 11, 2016

Member

I generally prefer to make a holistic analysis of an area of the library to making fixes that are likely to be obsoleted by something that looks very different. If you feel that there’s a better answer to be had with a broader analysis, I'd suggest we do that for Swift 4 or something. Otherwise, we should go ahead with the proposals as submitted.

Member

dabrahams commented Mar 11, 2016

I generally prefer to make a holistic analysis of an area of the library to making fixes that are likely to be obsoleted by something that looks very different. If you feel that there’s a better answer to be had with a broader analysis, I'd suggest we do that for Swift 4 or something. Otherwise, we should go ahead with the proposals as submitted.

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Mar 13, 2016

Collaborator

I suspect there's a better answer to be had with a broader analysis.

-- E

On Mar 11, 2016, at 4:48 PM, Dave Abrahams notifications@github.com wrote:

I generally prefer to make a holistic analysis of an area of the library to making fixes that are likely to be obsoleted by something that looks very different. If you feel that there’s a better answer to be had with a broader analysis, I'd suggest we do that for Swift 4 or something. Otherwise, we should go ahead with the proposals as submitted.


Reply to this email directly or view it on GitHub #184 (comment).

Collaborator

erica commented Mar 13, 2016

I suspect there's a better answer to be had with a broader analysis.

-- E

On Mar 11, 2016, at 4:48 PM, Dave Abrahams notifications@github.com wrote:

I generally prefer to make a holistic analysis of an area of the library to making fixes that are likely to be obsoleted by something that looks very different. If you feel that there’s a better answer to be had with a broader analysis, I'd suggest we do that for Swift 4 or something. Otherwise, we should go ahead with the proposals as submitted.


Reply to this email directly or view it on GitHub #184 (comment).

dabrahams added a commit that referenced this pull request Mar 15, 2016

dabrahams added a commit that referenced this pull request Mar 15, 2016

@erica erica deleted the erica:stride branch Mar 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment