I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.
https://github.com/apple/swift/pull/2981
My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.
--
Dave
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.
I didn't participate in this discussion but want to say that I am pleased with where it ended up. IMO this looks much better than the earlier version as well as some of the alternative that were discussed. I think brevity is important for the common functional operators and was previously concerned with the length of some of the names.
My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.
Some cases are more awkward than others. The value added by a label is also greater in some cases than others. Unfortunately I think these tend to coincide.
That said, I do think the value of a label outweighs the awkwardness in cases like min and max.
One change you might consider is to use different labels for comparison and equivalence relations. 'by' feels more natural in the context of comparisons and brevity feels more important in the methods that use a comparator. On the other hand, I think dropping the use of the word equivalent for 'starts' and 'elementsEqual' feels like a step back in clarity. Maybe we use 'equivalentBy' in these cases.
A suggestion for the future enhancements - rename elementsEqual to elementsEquivalent. If we make that change the shorter 'by' label would feel much less awkward to me in this method.
-Matthew
Sent from my iPad
On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
--
Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants
to have so many extra labels when a very simple phrase is understandable on its own
(e.g. max, min, sort, sorted).
Is it possible under the Swift umbrella to do the same for split since it has the rarely used
maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})`
and `split(atWhitespace)`.
Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?
If the former, I have opinions (new lines, new lines and whitespace)
The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?
If so, no worries. If not, helpful ping.
Future Extensions:
* reduce(_:, combine:) // way simpler
* "The argument against changing other names to be more consistent with API guidelines
is weakened. "
I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
`select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
a substitutable alias for fp aficionados.
This approach is not anything I've ever seen previously in a programming language but
its something that jumps out as a way to satisfy two distinct audiences of users
that would have limited impact but a decided advantage.
That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.
-- E
On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.
Dave Abrahams via swift-evolution <swift-evolution@...> writes:
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.
In sort, by: makes perfect sense.
In lexicographicallyPrecedes (elementsEqual), by: makes some sense,
because Precedes (Equal) is in method name.
starts(with:by:) looks odd, maybe starts(with:comparingBy:) ?
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.https://github.com/apple/swift/pull/2981
My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants
to have so many extra labels when a very simple phrase is understandable on its own
(e.g. max, min, sort, sorted).Is it possible under the Swift umbrella to do the same for split since it has the rarely used
maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})`
and `split(atWhitespace)`.Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?
If the former, I have opinions (new lines, new lines and whitespace)The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?
If so, no worries. If not, helpful ping.Future Extensions:
* reduce(_:, combine:) // way simpler
* "The argument against changing other names to be more consistent with API guidelines
is weakened. "I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
`select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
a substitutable alias for fp aficionados.
This approach is not anything I've ever seen previously in a programming language but
its something that jumps out as a way to satisfy two distinct audiences of users
that would have limited impact but a decided advantage.
Aliasing methods is pretty common in Ruby. The advantage is that you can select the alias that reads best at a specific call site. The disadvantage is that everyone has to learn more than one name for the same thing.
If we’re going to allow aliases I think it should be in support of clarity at specific call sites. I think the hurdle for this is pretty high and I’m not sure we would find the benefits to outweigh the drawbacks, but it is a discussion we could have. I would want to see concrete examples (which could be drawn from Ruby code).
I don’t think we should do this just to support term-of-art aliases where we believe we have a different name that fits Swift better. This creates “dialects” which I believe is a stated anti-goal of Swift.
It may turn out that existing terms of art provide enhanced clarity in some contexts and more Swifty names in others, in which case the alias may make sense. But it if we add them it should be done on the grounds of clarity and be accompanied by guidelines regarding which name to choose.
But my hunch is that this introduces more complexity than value.
On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Well,
x.elementsEquivalent(y, by: areSameExceptForCase)
is more ungrammatical than
x.elementsEqual(y, by: areSameExceptForCase)
and breaks the connection with
x.elementsEqual(y)
somewhat.
Maybe changing the closure parameter name to “areEqual” would be a
better choice.
on Wed Jun 29 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
A suggestion for the future enhancements - rename elementsEqual to
elementsEquivalent. If we make that change the shorter 'by' label
would feel much less awkward to me in this method.
--
Dave
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.https://github.com/apple/swift/pull/2981
My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.I'd be happy to see `by` labels go away, whether first or
trailing. I'm not sure why Swift 3 wants to have so many extra labels
when a very simple phrase is understandable on its own (e.g. max, min,
sort, sorted).
Well, it's simple: the labels aren't extra because x.sort(y) sounds like
x is sorting y.
Is it possible under the Swift umbrella to do the same for split since
it has the rarely used maxSplits, and omittingEmptySubsequences
params?
? AFAICT a decision about dropping the label has nothing to do with
those other parameters
It would give you `split({$0 == " "})` and `split(atWhitespace)`.
It wouldn't, because your predicate that identifies whitespace is not
going to be called, “atWhitespace”
Speaking of isAllWhitespace, would this be a prebuilt enumeration or
is it a placeholder?
It's not an enumeration; we're talking about closure parameters,
remember? It's a hypothetical predicate:
func isAllWhitespace(_: String) -> Bool
If the former, I have opinions (new lines, new lines and whitespace)
The managed buffer, are you "makingValueWith" instead of
"makingHeaderWith" intentionally?
Yes, because the change from “Value” to “Header” is a separate proposal
that you have kindly written up for me.
If so, no worries. If not, helpful ping.
Future Extensions:
* reduce(_:, combine:) // way simpler
* "The argument against changing other names to be more consistent with API guidelines
is weakened. "I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
`select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
a substitutable alias for fp aficionados.This approach is not anything I've ever seen previously in a programming language but
its something that jumps out as a way to satisfy two distinct audiences of users
that would have limited impact but a decided advantage.That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.
Separate discussion, but thanks for the input. Let's handle that stuff
in a separate review. I should probably strip it out of the pull
request text.
on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:
On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
--
Dave
Dave Abrahams via swift-evolution <swift-evolution@...> writes:
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.In sort, by: makes perfect sense.
In lexicographicallyPrecedes (elementsEqual), by: makes some sense,
because Precedes (Equal) is in method name.
I don't understand your reasoning here. How does “precedes” being in the
method name relate to “by?”
starts(with:by:) looks odd, maybe starts(with:comparingBy:) ?
“starts(with” is in the method name; how is this different?
on Wed Jun 29 2016, Anton Zhilin <swift-evolution@swift.org> wrote:
--
Dave
Sent from my iPad
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.I didn't participate in this discussion but want to say that I am
pleased with where it ended up. IMO this looks much better than the
earlier version as well as some of the alternative that were
discussed. I think brevity is important for the common functional
operators and was previously concerned with the length of some of the
names.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.Some cases are more awkward than others. The value added by a label
is also greater in some cases than others. Unfortunately I think
these tend to coincide.That said, I do think the value of a label outweighs the awkwardness
in cases like min and max.
? min and max are not under discussion here.
on Wed Jun 29 2016, Matthew Johnson <swift-evolution@swift.org> wrote:
On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
One change you might consider is to use different labels for
comparison and equivalence relations. 'by' feels more natural in the
context of comparisons and brevity feels more important in the methods
that use a comparator. On the other hand, I think dropping the use of
the word equivalent for 'starts' and 'elementsEqual' feels like a step
back in clarity. Maybe we use 'equivalentBy' in these cases.A suggestion for the future enhancements - rename elementsEqual to
elementsEquivalent. If we make that change the shorter 'by' label
would feel much less awkward to me in this method.-Matthew
--
Dave_______________________________________________
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
--
Dave
Don't forget QuickHelp and module interfaces, which automatically list attributes along with the declaration.
On Jun 29, 2016, at 9:37 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
`select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
a substitutable alias for fp aficionados.
This approach is not anything I've ever seen previously in a programming language but
its something that jumps out as a way to satisfy two distinct audiences of users
that would have limited impact but a decided advantage.Aliasing methods is pretty common in Ruby. The advantage is that you can select the alias that reads best at a specific call site. The disadvantage is that everyone has to learn more than one name for the same thing.
If we’re going to allow aliases I think it should be in support of clarity at specific call sites. I think the hurdle for this is pretty high and I’m not sure we would find the benefits to outweigh the drawbacks, but it is a discussion we could have. I would want to see concrete examples (which could be drawn from Ruby code).
I don’t think we should do this just to support term-of-art aliases where we believe we have a different name that fits Swift better. This creates “dialects” which I believe is a stated anti-goal of Swift.
It may turn out that existing terms of art provide enhanced clarity in some contexts and more Swifty names in others, in which case the alias may make sense. But it if we add them it should be done on the grounds of clarity and be accompanied by guidelines regarding which name to choose.
But my hunch is that this introduces more complexity than value.
>
>
>>
>>
>> I've updated my pull request with a much more conservative set of
>> changes that preserves/restores label-free-ness for all “term of art”
>> functional methods such as filter and reduce.
>>
>> Name and label changes for closure parameters (SE-0118) by dabrahams · Pull Request #2981 · apple/swift · GitHub
>>
>> My current thoughts are that many of the `by:` labels are awkward and
>> not adding much. Perhaps they all ought to be omitted.
>
>
> I'd be happy to see `by` labels go away, whether first or trailing. I'm
not sure why Swift 3 wants
> to have so many extra labels when a very simple phrase is understandable
on its own
> (e.g. max, min, sort, sorted).
>
> Is it possible under the Swift umbrella to do the same for split since
it has the rarely used
> maxSplits, and omittingEmptySubsequences params? It would give you
`split({$0 == " "})`
> and `split(atWhitespace)`.
>
> Speaking of isAllWhitespace, would this be a prebuilt enumeration or is
it a placeholder?
> If the former, I have opinions (new lines, new lines and whitespace)
>
> The managed buffer, are you "makingValueWith" instead of
"makingHeaderWith" intentionally?
> If so, no worries. If not, helpful ping.
>
> Future Extensions:
>
> * reduce(_:, combine:) // way simpler
>
> * "The argument against changing other names to be more consistent with
API guidelines
> is weakened. "
>
> I think Sean Heber's `@termOfArt(name)` is a great way to have both
worlds, where
> `select(where:)` or `where()` is the Swifty name and
`@termOfArt(filter)` offers
> a substitutable alias for fp aficionados.
> This approach is not anything I've ever seen previously in a programming
language but
> its something that jumps out as a way to satisfy two distinct audiences
of users
> that would have limited impact but a decided advantage.Aliasing methods is pretty common in Ruby. The advantage is that you can
select the alias that reads best at a specific call site. The disadvantage
is that everyone has to learn more than one name for the same thing.If we’re going to allow aliases I think it should be in support of clarity
at specific call sites. I think the hurdle for this is pretty high and I’m
not sure we would find the benefits to outweigh the drawbacks, but it is a
discussion we could have. I would want to see concrete examples (which
could be drawn from Ruby code).I don’t think we should do this just to support term-of-art aliases where
we believe we have a different name that fits Swift better. This creates
“dialects” which I believe is a stated anti-goal of Swift.It may turn out that existing terms of art provide enhanced clarity in
some contexts and more Swifty names in others, in which case the alias may
make sense. But it if we add them it should be done on the grounds of
clarity and be accompanied by guidelines regarding which name to choose.But my hunch is that this introduces more complexity than value.
Agreed. I'd have to be convinced that having aliases provide overwhelming
wins at the call site that could not be achieved through renaming. Although
aliasing could be very neat in certain circumstances, I fear that admitting
such a facility to the language is an "out" that would discourage
exploration of the most appropriate method names and consensus-building in
favor of "you'll have yours and I'll have mine," which would be fatal for
building a coherent set of APIs.
On Wed, Jun 29, 2016 at 10:37 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:
> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>
> That said, I don't like `mapping` and `flattened`. If they're going to
be Swiftized, go with
> names that aren't standing in the "term of art" rubble: transform,
squeeze, whatever.
>
> -- E
>
>
>
> _______________________________________________
> 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
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants
to have so many extra labels when a very simple phrase is understandable on its own
(e.g. max, min, sort, sorted).Is it possible under the Swift umbrella to do the same for split since it has the rarely used
maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})`
and `split(atWhitespace)`.Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?
If the former, I have opinions (new lines, new lines and whitespace)The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?
If so, no worries. If not, helpful ping.Future Extensions:
* reduce(_:, combine:) // way simpler
* "The argument against changing other names to be more consistent with API guidelines
is weakened. "I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
`select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
a substitutable alias for fp aficionados.
This approach is not anything I've ever seen previously in a programming language but
its something that jumps out as a way to satisfy two distinct audiences of users
that would have limited impact but a decided advantage.Aliasing methods is pretty common in Ruby. The advantage is that you
can select the alias that reads best at a specific call site. The
disadvantage is that everyone has to learn more than one name for the
same thing.
Yeah, I'd rather not do that.
If we’re going to allow aliases I think it should be in support of
clarity at specific call sites. I think the hurdle for this is pretty
high and I’m not sure we would find the benefits to outweigh the
drawbacks, but it is a discussion we could have. I would want to see
concrete examples (which could be drawn from Ruby code).I don’t think we should do this just to support term-of-art aliases
where we believe we have a different name that fits Swift better.
This creates “dialects” which I believe is a stated anti-goal of
Swift.
+1
on Wed Jun 29 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
It may turn out that existing terms of art provide enhanced clarity in
some contexts and more Swifty names in others, in which case the alias
may make sense. But it if we add them it should be done on the
grounds of clarity and be accompanied by guidelines regarding which
name to choose.But my hunch is that this introduces more complexity than value.
That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
Could we please take all the discussion of aliasing and the future
extensions bit of this PR into a different thread? I'd like to keep
this discussion focused.
Thanks,
Dave
on Wed Jun 29 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants
to have so many extra labels when a very simple phrase is understandable on its own
(e.g. max, min, sort, sorted).Is it possible under the Swift umbrella to do the same for split since it has the rarely used
maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})`
and `split(atWhitespace)`.Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?
If the former, I have opinions (new lines, new lines and whitespace)The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?
If so, no worries. If not, helpful ping.Future Extensions:
* reduce(_:, combine:) // way simpler
* "The argument against changing other names to be more consistent with API guidelines
is weakened. "I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
`select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
a substitutable alias for fp aficionados.
This approach is not anything I've ever seen previously in a programming language but
its something that jumps out as a way to satisfy two distinct audiences of users
that would have limited impact but a decided advantage.Aliasing methods is pretty common in Ruby. The advantage is that you
can select the alias that reads best at a specific call site. The
disadvantage is that everyone has to learn more than one name for the
same thing.If we’re going to allow aliases I think it should be in support of
clarity at specific call sites. I think the hurdle for this is pretty
high and I’m not sure we would find the benefits to outweigh the
drawbacks, but it is a discussion we could have. I would want to see
concrete examples (which could be drawn from Ruby code).I don’t think we should do this just to support term-of-art aliases
where we believe we have a different name that fits Swift better.
This creates “dialects” which I believe is a stated anti-goal of
Swift.It may turn out that existing terms of art provide enhanced clarity in
some contexts and more Swifty names in others, in which case the alias
may make sense. But it if we add them it should be done on the
grounds of clarity and be accompanied by guidelines regarding which
name to choose.But my hunch is that this introduces more complexity than value.
That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
Sent from my iPad
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.I didn't participate in this discussion but want to say that I am
pleased with where it ended up. IMO this looks much better than the
earlier version as well as some of the alternative that were
discussed. I think brevity is important for the common functional
operators and was previously concerned with the length of some of the
names.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.Some cases are more awkward than others. The value added by a label
is also greater in some cases than others. Unfortunately I think
these tend to coincide.That said, I do think the value of a label outweighs the awkwardness
in cases like min and max.? min and max are not under discussion here.
Really? It looks like they're in your table:
smallest = shapes.min(
isOrderedBefore: haveIncreasingSize)
smallest = shapes.min(
by: haveIncreasingSize)
largest = shapes.max(
isOrderedBefore: haveIncreasingSize)
largest = shapes.max(
by: haveIncreasingSize)
Sent from my iPad
On Jul 1, 2016, at 7:03 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 29 2016, Matthew Johnson <swift-evolution@swift.org> wrote:
On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
One change you might consider is to use different labels for
comparison and equivalence relations. 'by' feels more natural in the
context of comparisons and brevity feels more important in the methods
that use a comparator. On the other hand, I think dropping the use of
the word equivalent for 'starts' and 'elementsEqual' feels like a step
back in clarity. Maybe we use 'equivalentBy' in these cases.A suggestion for the future enhancements - rename elementsEqual to
elementsEquivalent. If we make that change the shorter 'by' label
would feel much less awkward to me in this method.-Matthew
--
Dave_______________________________________________
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--
Dave_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>>
>>
>> I've updated my pull request with a much more conservative set of
>> changes that preserves/restores label-free-ness for all “term of art”
>> functional methods such as filter and reduce.
>>
>> Name and label changes for closure parameters (SE-0118) by dabrahams · Pull Request #2981 · apple/swift · GitHub
>>
>> My current thoughts are that many of the `by:` labels are awkward and
>> not adding much. Perhaps they all ought to be omitted.
>
>
> I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants
> to have so many extra labels when a very simple phrase is understandable on its own
> (e.g. max, min, sort, sorted).
>
> Is it possible under the Swift umbrella to do the same for split since it has the rarely used
> maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})`
> and `split(atWhitespace)`.
>
> Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?
> If the former, I have opinions (new lines, new lines and whitespace)
>
> The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?
> If so, no worries. If not, helpful ping.
>
> Future Extensions:
>
> * reduce(_:, combine:) // way simpler
>
> * "The argument against changing other names to be more consistent with API guidelines
> is weakened. "
>
> I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where
> `select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
> a substitutable alias for fp aficionados.
> This approach is not anything I've ever seen previously in a programming language but
> its something that jumps out as a way to satisfy two distinct audiences of users
> that would have limited impact but a decided advantage.Aliasing methods is pretty common in Ruby. The advantage is that you can select the alias that reads best at a specific call site. The disadvantage is that everyone has to learn more than one name for the same thing.
If we’re going to allow aliases I think it should be in support of clarity at specific call sites. I think the hurdle for this is pretty high and I’m not sure we would find the benefits to outweigh the drawbacks, but it is a discussion we could have. I would want to see concrete examples (which could be drawn from Ruby code).
I don’t think we should do this just to support term-of-art aliases where we believe we have a different name that fits Swift better. This creates “dialects” which I believe is a stated anti-goal of Swift.
It may turn out that existing terms of art provide enhanced clarity in some contexts and more Swifty names in others, in which case the alias may make sense. But it if we add them it should be done on the grounds of clarity and be accompanied by guidelines regarding which name to choose.
But my hunch is that this introduces more complexity than value.
Agreed. I'd have to be convinced that having aliases provide overwhelming wins at the call site that could not be achieved through renaming. Although aliasing could be very neat in certain circumstances, I fear that admitting such a facility to the language is an "out" that would discourage exploration of the most appropriate method names and consensus-building in favor of "you'll have yours and I'll have mine," which would be fatal for building a coherent set of APIs.
My experience with Ruby has been primarily writing scripts for my own use. If we’re going to consider aliases it would be great to hear about how this has impacted larger teams and the broader Ruby community. I’m not sure whether it is viewed as a net win or a source of confusion. I don’t think the situation is quite as dire as you fear, but it is a very valid concern.
On Jun 29, 2016, at 11:01 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Jun 29, 2016 at 10:37 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote:
> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
> names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.
>
> -- E
>
>
>
> _______________________________________________
> 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
Agreed. I'd have to be convinced that having aliases provide overwhelming wins at the call site that could not be achieved through renaming. Although aliasing could be very neat in certain circumstances, I fear that admitting such a facility to the language is an "out" that would discourage exploration of the most appropriate method names and consensus-building in favor of "you'll have yours and I'll have mine," which would be fatal for building a coherent set of APIs.
It would probably be quite difficult to prove (although that doesn’t mean it isn’t worth trying) that aliases would be an overwhelming win because everyone has different tolerances for impedance mismatches. In many ways, it is that difference of tolerance that is the issue here (and in a few other threads).
I personally have no desire to fragment things more than necessary, but I also really want code to read fluently. These goals seem to be at odds and, I speculate, they are at odds in ways that are impossible to solve with a single solution. Human languages have a lot of redundancy and variety for a reason, and we’ve taken the stance that Swift should read with a kind of “flow” that we usually only associate with human languages. This means that there are likely going to have to be concessions made to Swift that one might not ordinarily see in a programming language. (IMO)
The argument that aliases would be “fatal” for building coherent API doesn’t seem to tell the whole story to me. After all, every program ultimately has it’s own “language” of sorts that is built up from the building blocks of the standard library and other included frameworks. There’s a unique mix of the usage of certain words, constructs, names in each program that is a reflection of the programmers who have built the program and each one reads differently no matter how hard we might try to have only “one true way” to express a thing.
To me, one of the nicer aspects of having aliases encoded in the API as function attributes is that, in the case of the standard libraries, they would be decided and bikeshedded by the usual suspects and then effectively locked into place. There’s still control on the extent of use of this feature. You cannot add an alias by way of an extension in your own code, for example, and I think that’s a fine tradeoff. It would be surgically used and, mostly, only by the core team/standard lib API designers and by those who wish to experiment. I don’t know if that’s a big win or not. To me, this feels like mostly untested territory.
l8r
Sean
Sent from my iPad
Sent from my iPad
I've updated my pull request with a much more conservative set of
changes that preserves/restores label-free-ness for all “term of art”
functional methods such as filter and reduce.I didn't participate in this discussion but want to say that I am
pleased with where it ended up. IMO this looks much better than the
earlier version as well as some of the alternative that were
discussed. I think brevity is important for the common functional
operators and was previously concerned with the length of some of the
names.My current thoughts are that many of the `by:` labels are awkward and
not adding much. Perhaps they all ought to be omitted.Some cases are more awkward than others. The value added by a label
is also greater in some cases than others. Unfortunately I think
these tend to coincide.That said, I do think the value of a label outweighs the awkwardness
in cases like min and max.? min and max are not under discussion here.
Really? It looks like they're in your table:
smallest = shapes.min(
isOrderedBefore: haveIncreasingSize)
smallest = shapes.min(
by: haveIncreasingSize)largest = shapes.max(
isOrderedBefore: haveIncreasingSize)
largest = shapes.max(
by: haveIncreasingSize)
Oops, sorry, you're right.
One change you might consider is to use different labels for
comparison and equivalence relations. 'by' feels more natural in the
context of comparisons and brevity feels more important in the methods
that use a comparator. On the other hand, I think dropping the use of
the word equivalent for 'starts' and 'elementsEqual' feels like a step
back in clarity. Maybe we use 'equivalentBy' in these cases.
I have a hard time justifying that to myself. Taking the examples from
the PR,
if expected.elementsEqual(actual, by: haveSameValue) { ... }
if names.starts(with: myFamily, by: areSameExceptForCase) { ... }
vs.
if expected.elementsEqual(actual, equivalentBy: haveSameValue) { ... }
if names.starts(with: myFamily, equivalentBy: areSameExceptForCase) { ... }
If I was going to add words to “by,” I'd go with “determinedBy:”
if expected.elementsEqual(actual, determinedBy: haveSameValue) { ... }
if names.starts(with: myFamily, determinedBy: areSameExceptForCase) { ... }
but then I think that applies equally well to min and max, which are
doing ordering comparison instead of equality.
A suggestion for the future enhancements - rename elementsEqual to
elementsEquivalent. If we make that change the shorter 'by' label
would feel much less awkward to me in this method.
Then the basename connection between the predicated and non-predicated
elementsEqual is broken. Not out of the question, but doesn't seem
worth it to me.
on Fri Jul 01 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
On Jul 1, 2016, at 7:03 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 29 2016, Matthew Johnson <swift-evolution@swift.org> wrote:
On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
--
Dave
> Agreed. I'd have to be convinced that having aliases provide
overwhelming wins at the call site that could not be achieved through
renaming. Although aliasing could be very neat in certain circumstances, I
fear that admitting such a facility to the language is an "out" that would
discourage exploration of the most appropriate method names and
consensus-building in favor of "you'll have yours and I'll have mine,"
which would be fatal for building a coherent set of APIs.It would probably be quite difficult to prove (although that doesn’t mean
it isn’t worth trying) that aliases would be an overwhelming win because
everyone has different tolerances for impedance mismatches. In many ways,
it is that difference of tolerance that is the issue here (and in a few
other threads).I personally have no desire to fragment things more than necessary, but I
also really want code to read fluently. These goals seem to be at odds and,
I speculate, they are at odds in ways that are impossible to solve with a
single solution. Human languages have a lot of redundancy and variety for a
reason, and we’ve taken the stance that Swift should read with a kind of
“flow” that we usually only associate with human languages. This means that
there are likely going to have to be concessions made to Swift that one
might not ordinarily see in a programming language. (IMO)
I disagree with your interpretation of "Swifty" here. I understand the
supreme aim for Swift naming to be clarity, especially at the call site. In
some places, that would require Obj-C/Cocoa-like verbosity; in others it
calls for terseness. In some places, it should read more "fluently", in
others not as much (e.g. arguments inside `init()` omit the classic
preposition "with"). So I would disagree that we should make concessions to
"fluency" but rather to clarity. And as for clarity, two names for the same
thing are, ipso facto, less clear than one, which is why I argue that the
wins would have to be "overwhelming".
The argument that aliases would be “fatal” for building coherent API
doesn’t seem to tell the whole story to me. After all, every program
ultimately has it’s own “language” of sorts that is built up from the
building blocks of the standard library and other included frameworks.
There’s a unique mix of the usage of certain words, constructs, names in
each program that is a reflection of the programmers who have built the
program and each one reads differently no matter how hard we might try to
have only “one true way” to express a thing.
I was more writing in relation to the topics discussed here--i.e. stdlib
and corelibs naming--and not so much in relation to user code. Within an
API, I'd argue there should very much be only one "language", especially
given that any particular program may ultimately use many frameworks, since
one "language" from each framework could already be a lot to handle.
To me, one of the nicer aspects of having aliases encoded in the API as
function attributes is that, in the case of the standard libraries, they
would be decided and bikeshedded by the usual suspects and then effectively
locked into place. There’s still control on the extent of use of this
feature. You cannot add an alias by way of an extension in your own code,
for example, and I think that’s a fine tradeoff. It would be surgically
used and, mostly, only by the core team/standard lib API designers and by
those who wish to experiment. I don’t know if that’s a big win or not. To
me, this feels like mostly untested territory.
See, here I would be precisely against that use for aliasing. For your own
code and as an extension, maybe. But as I argue above, definitely not for
stdlib and definitely not at the point of declaration.
On Wed, Jun 29, 2016 at 11:19 AM, Sean Heber <sean@fifthace.com> wrote:
l8r
Sean
I have experience using aliases in Ruby and they are one of the aspects of the language I hated with a passion. They can be very confusing, and increase the difficulty of learning the APIs and QuickHelp is not always there to help. To me, they sound like a convenience for the code writer but a nuisance of the reader. And Swift has always tried to improve its readability over its writability.
On 29 Jun 2016, at 18:19, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
Agreed. I'd have to be convinced that having aliases provide overwhelming wins at the call site that could not be achieved through renaming. Although aliasing could be very neat in certain circumstances, I fear that admitting such a facility to the language is an "out" that would discourage exploration of the most appropriate method names and consensus-building in favor of "you'll have yours and I'll have mine," which would be fatal for building a coherent set of APIs.
It would probably be quite difficult to prove (although that doesn’t mean it isn’t worth trying) that aliases would be an overwhelming win because everyone has different tolerances for impedance mismatches. In many ways, it is that difference of tolerance that is the issue here (and in a few other threads).
I personally have no desire to fragment things more than necessary, but I also really want code to read fluently. These goals seem to be at odds and, I speculate, they are at odds in ways that are impossible to solve with a single solution. Human languages have a lot of redundancy and variety for a reason, and we’ve taken the stance that Swift should read with a kind of “flow” that we usually only associate with human languages. This means that there are likely going to have to be concessions made to Swift that one might not ordinarily see in a programming language. (IMO)
The argument that aliases would be “fatal” for building coherent API doesn’t seem to tell the whole story to me. After all, every program ultimately has it’s own “language” of sorts that is built up from the building blocks of the standard library and other included frameworks. There’s a unique mix of the usage of certain words, constructs, names in each program that is a reflection of the programmers who have built the program and each one reads differently no matter how hard we might try to have only “one true way” to express a thing.
To me, one of the nicer aspects of having aliases encoded in the API as function attributes is that, in the case of the standard libraries, they would be decided and bikeshedded by the usual suspects and then effectively locked into place. There’s still control on the extent of use of this feature. You cannot add an alias by way of an extension in your own code, for example, and I think that’s a fine tradeoff. It would be surgically used and, mostly, only by the core team/standard lib API designers and by those who wish to experiment. I don’t know if that’s a big win or not. To me, this feels like mostly untested territory.
l8r
Sean_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I wasn’t aware of this being a thing in Ruby - interesting! Perhaps it is not so untested territory after all. :) Would be interesting to see if whatever prompted your hatred of it there is due to how it works in Ruby vs. the idea itself or not, though. Not sure how one would go about determining that, though. Or if that’d even be a useful result.
l8r
Sean
On Jun 29, 2016, at 12:14 PM, David Hart <david@hartbit.com> wrote:
I have experience using aliases in Ruby and they are one of the aspects of the language I hated with a passion. They can be very confusing, and increase the difficulty of learning the APIs and QuickHelp is not always there to help. To me, they sound like a convenience for the code writer but a nuisance of the reader. And Swift has always tried to improve its readability over its writability.
On 29 Jun 2016, at 18:19, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
Agreed. I'd have to be convinced that having aliases provide overwhelming wins at the call site that could not be achieved through renaming. Although aliasing could be very neat in certain circumstances, I fear that admitting such a facility to the language is an "out" that would discourage exploration of the most appropriate method names and consensus-building in favor of "you'll have yours and I'll have mine," which would be fatal for building a coherent set of APIs.
It would probably be quite difficult to prove (although that doesn’t mean it isn’t worth trying) that aliases would be an overwhelming win because everyone has different tolerances for impedance mismatches. In many ways, it is that difference of tolerance that is the issue here (and in a few other threads).
I personally have no desire to fragment things more than necessary, but I also really want code to read fluently. These goals seem to be at odds and, I speculate, they are at odds in ways that are impossible to solve with a single solution. Human languages have a lot of redundancy and variety for a reason, and we’ve taken the stance that Swift should read with a kind of “flow” that we usually only associate with human languages. This means that there are likely going to have to be concessions made to Swift that one might not ordinarily see in a programming language. (IMO)
The argument that aliases would be “fatal” for building coherent API doesn’t seem to tell the whole story to me. After all, every program ultimately has it’s own “language” of sorts that is built up from the building blocks of the standard library and other included frameworks. There’s a unique mix of the usage of certain words, constructs, names in each program that is a reflection of the programmers who have built the program and each one reads differently no matter how hard we might try to have only “one true way” to express a thing.
To me, one of the nicer aspects of having aliases encoded in the API as function attributes is that, in the case of the standard libraries, they would be decided and bikeshedded by the usual suspects and then effectively locked into place. There’s still control on the extent of use of this feature. You cannot add an alias by way of an extension in your own code, for example, and I think that’s a fine tradeoff. It would be surgically used and, mostly, only by the core team/standard lib API designers and by those who wish to experiment. I don’t know if that’s a big win or not. To me, this feels like mostly untested territory.
l8r
Sean_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution