Re: [swift-evolution] [Proposal] Random Unification

[Brent Royal-Gordon via swift-evolution]

On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evolution 
 wrote:
> 
> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array 
> (RandomAccessSequence?), they should just be for convenience and with a sane 
> default RNG*, and users that need more should just use methods on the RNGs 
> directly.

No—that means code which uses these extremely convenient and attractive APIs 
can never be testable and that there's no obvious way to go from "use the 
default RNG" to "use this specific RNG".

Methods which use an RNG should take that RNG as a parameter—a parameter with a 
default value of "the default RNG":

init(randomIn range: CountableRange, from randomizer: Randomizer 
= DefaultRandomizer.shared) {
…
}

This properly separates concerns between the Randomizer (which knows how to 
return random data) and the type (which knows how to construct itself from 
random data). It also makes it easy to use a randomized API you already knew 
about with a RandomSource, and it creates a convention that users can apply to 
their own designs for how to write testable and customizable randomized code. 
We might even add a local refactoring which automatically adds a Randomizer 
parameter to the function and passes it to randomized calls within the body.

Don't add a global setter—you don't know what it might affect. Don't add a 
bunch of calls constructing arbitrary types to the Randomizer (or whatever it's 
called) protocol. Do it with dependency injection: pass the Randomizer as a 
parameter.

-- 
Brent Royal-Gordon
Sent from my iPhone

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[Kevin Nattinger via swift-evolution]

–∞

1. I strongly object to the proposed name. It doesn't make it more clear to me 
what the method does, and is misleading at best. Among other issues, 
"lexicographical" is defined as alphabet order, and (1) this method applies to 
objects that are not Strings, and (2) this method's behavior isn't any more 
well-defined for Strings, so that name is even more of a lie than the original.

2. This is really just a symptom of a bigger problem. The fact that two Sets 
can compare equal and yet return different results for that method (among too 
many others) is logically inconsistent and points to a much deeper issue with 
Set and Sequence. It is probably about 3 releases too late to get this 
straightened out properly, but I'll outline the real issue in case someone has 
an idea for fixing it.

The root of the problem is that Set conforms to Sequence, but Sequence doesn't 
require a well-defined order. Since Set doesn't have a well-defined order, a 
significant portion of its interface is unspecified. The methods are 
implemented because they have to be, but they doesn't have well-defined or 
necessarily consistent results.

A sequence is, by definition, ordered. That is reflected in the fact that over 
half the methods in the main Sequence definition* make no sense and are not 
well-defined unless there is a well-defined order to the sequence itself. What 
does it even mean to `dropFirst()` in a Set? The fact that two objects that 
compare equal can give different results for a 100% deterministic function is 
illogical, nonsensical, and dangerous.

* 7/12 by my count, ignoring `_*` funcs but including the `var`

The current contents of Sequence can be cleanly divided into two groups; those 
that return SubSequence imply a specific ordering, and the rest do not.

 I think those should be/should have been two separate protocols:

public protocol Iterable {
  associatedtype Iterator: IteratorProtocol
  func map(...) -> [T] // Iterable where .Iterator.Element == T
  func filter(...) -> [Iterator.Element] // Iterable where .Iterator.Element == 
Self.Iterator.Element
  func forEach(...)
  func makeIterator() -> Iterator
  var underestimatedCount: Int { get }
}

public protocol Sequence: Iterable { // Maybe OrderedSequence just to make the 
well-defined-order requirement explicit
  associatedtype SubSequence
  func dropFirst(...)   -> SubSequence   // Sequence where .Iterator.Element == 
Self.Iterator.Element
  func dropLast(...)-> SubSequence   //" "
  func drop(while...)   -> SubSequence   //" "
  func prefix(...)  -> SubSequence   //" "
  func prefix(while...) -> SubSequence   //" "
  func suffix(...)  -> SubSequence   //" "
  func split(...where...)  -> [SubSequence] // Iterable where .Iterator.Element 
== (Sequence where .Iterator.Element == Self.Iterator.Element)
}

(The comments, of course, would be more sensible types once the ideas can 
actually be expressed in Swift)

Then unordered collections (Set and Dictionary) would just conform to Iterable 
and not Sequence, so ALL the methods on those classes would make logical sense 
and have well-defined behavior; no change would be needed for ordered 
collections.

Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there would 
be a significant issue with actually making this change. Unfortunately, we're 
well beyond that and making a change this deep is an enormous deal. So I see 
two ways forward.

1. We could go ahead and make this separation. Although it's a potentially 
large breaking change, I would argue that because the methods are ill-defined 
anyway, the breakage is justified and a net benefit.

2. We could try and think of a way to make the distinction between ordered and 
unordered "sequences" in a less-breaking manner. Unfortunately, I don't have a 
good suggestion for this, but if anyone has ideas, I'm all ears. Or eyes, as 
the case may be.


> On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Rename Sequence.elementsEqual
> 
> Proposal: SE- 
> Authors: Xiaodi Wu 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> The current behavior of Sequence.elementsEqual is potentially confusing to 
> users given its name. Having surveyed the alternative solutions to this 
> problem, it is proposed that the method be renamed to 
> Sequence.lexicographicallyEquals.
> 
> [...]
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[David Hart via swift-evolution]

+1

Agree with the reasoning and that this is the best solution. It reduces the 
risk of confusing the function for what it’s not.

> On 13 Oct 2017, at 01:37, Kelvin Ma via swift-evolution 
>  wrote:
> 
> I’ve always hated the use of the word “lexicographically” in that method 1) 
> because lexicographically is hard to spell, and 2) because it’s weird to say 
> that an unordered collection has a lexicographical order. But this change is 
> probably for the best.
> 
>> On Thu, Oct 12, 2017 at 6:24 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> Rename Sequence.elementsEqual
>> 
>> Proposal: SE-
>> Authors: Xiaodi Wu
>> Review Manager: TBD
>> Status: Awaiting review
>> Introduction
>> 
>> The current behavior of Sequence.elementsEqual is potentially confusing to 
>> users given its name. Having surveyed the alternative solutions to this 
>> problem, it is proposed that the method be renamed to 
>> Sequence.lexicographicallyEquals.
>> 
>> Motivation
>> 
>> As outlined by Ole Begemann, use of Sequence.elementsEqual(_:) can lead to 
>> surprising results if the sequences compared are unordered:
>> 
>> var set1: Set = Set(1...5)
>> var set2: Set = Set((1...5).reversed())
>> 
>> set1 == set2 // true
>> set1.elementsEqual(set2) // false
>> This result does reflect the intended and documented behavior of the 
>> elementsEqual(_:) method, which performs a lexicographical elementwise 
>> comparison. That is, the method first compares set1.first to set2.first, 
>> then (if the two elements compare equal) compares the next element stored 
>> internally in set1 to the next element stored internally in set2, and so on.
>> 
>> In almost all circumstances where a set is compared to another set, or a 
>> dictionary is compared to another dictionary, users should use == instead of 
>> elementsEqual(_:).
>> 
>> Proposed solution
>> 
>> The proposed solution is the result of an iterative process of reasoning, 
>> presented here:
>> 
>> The first and most obvious solution is to remove the elementsEqual(_:) 
>> method altogether in favor of ==. This prevents its misuse. However, because 
>> elementsEqual(_:) is a generic method on Sequence, we can use it to compare 
>> an instance of UnsafeBufferPointer to an instance of [Int]. This is a 
>> useful and non-redundant feature which would be eliminated if the method is 
>> removed altogether.
>> 
>> A second solution is to create overloads that forbid the use of the 
>> elementsEqual(_:) method specifically in non-generic code. This would 
>> prevent misuse in non-generic code; however, it would also forbid legitimate 
>> mixed-type comparisons in non-generic code while failing to prevent misuse 
>> in generic code. The solution also creates a difference in the behavior of 
>> generic and non-generic code calling the same method, which is potentially 
>> confusing, without solving the problem completely.
>> 
>> A third solution is to dramatically overhaul the protocol hierarchy for 
>> Swift sequences and collections so that unordered collections no longer have 
>> members such as first and elementsEqual(_:). However, this would be a 
>> colossal and source-breaking undertaking, and it is unlikely to be 
>> satisfactory in addressing all the axes of differences among sequence and 
>> collection types:
>> 
>> Finite versus infinite
>> Single-pass versus multi-pass
>> Ordered versus unordered
>> Lazy versus eager
>> Forward/bidirectional/random-access
>> A fourth solution is proposed here. It is predicated on the following 
>> observation:
>> 
>> Another method similar to elementsEqual(_:) already exists on Sequence named 
>> lexicographicallyPrecedes(_:). Like first, elementsEqual(_:), drop(while:), 
>> and others, it relies on the internal order of elements in a manner that is 
>> not completely suitable for an unordered collection. However, like first and 
>> unlike elementsEqual(_:), this fact is called out in the name of the method; 
>> unsurprisingly, like first and unlike elementsEqual(_:), there is no 
>> evidence that lexicographicallyPrecedes(_:) has been a pitfall for users.
>> 
>> This observation suggests that a major reason for confusion over 
>> elementsEqual(_:) stems from its name. So, it is proposed that 
>> elementsEqual(_:) should be renamed to lexicographicallyEquals(_:). The 
>> function will remain somewhat of a poor fit for unordered collections, but 
>> no more so than many other methods that cannot trivially be removed from the 
>> API of unordered collections (as discussed above). The key is that, with 
>> such a renaming, the behavior of this method will no longer be confusing.
>> 
>> Detailed design
>> 
>> extension Sequence where Element : Equatable {
>>   @available(*, deprecated, message: "Use '==' if possible to compare two 
>> sequences of the same type, or use 'lexicographicallyEquals' to compare two 
>> ordered sequences.")
>>   public func elementsEqual(
>> _ other: Other
>>   ) -> 

Re: [swift-evolution] commas optional

[Chris Lattner via swift-evolution]

Hi Dave,

I agree with you that this is an analogous technical problem to semicolon 
inference, and that Swift has a well developed solution for it which would 
probably work well enough.

That said, this is a pure sugar proposal, one which can make future evolution 
more difficult.  Getting this into Swift 5 will be very very difficult to 
justify, even if the community somehow agreed that it was the right thing to 
do.  It is just the conservatively correct default to say “no” to these sorts 
of changes now, because there are other bigger moving pieces that have to be 
sorted first.

-Chris



> On Oct 12, 2017, at 11:50 AM, Dave Yost via swift-evolution 
>  wrote:
> 
> 
> Speaking as a huge fan of optional semicolons...
> 
> 
> This seems clear:
> 
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
> 
> and so it occurred to me that this should hold:
> 
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
> 
>   ∴  A comma after the last array element on a line should be optional.
> 
> and these should be legal Swift:
> 
>   let list = [
>   1
>   2
>   ]
> 
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
> 
> equivalent to:
> 
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
> 
> 
> Or, as the Language Reference would say:
> 
> A semicolon (;) can optionally appear after any statement and is used to 
> separate multiple statements if they appear on the same line.
> 
> A comma (,) can optionally appear after any element of an array literal and 
> is used to separate multiple elements if they appear on the same line.
> 
> Or:
> 
> A semicolon (;) separates statements but is optional after the last statement 
> on a line.
> 
> A comma (,) separates elements of an array literal but is optional after the 
> last element on a line.
> 
> 
> ___
> 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

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[Kelvin Ma via swift-evolution]

I’ve always hated the use of the word “lexicographically” in that method 1)
because lexicographically is hard to spell, and 2) because it’s weird to
say that an unordered collection has a lexicographical order. But this
change is probably for the best.

On Thu, Oct 12, 2017 at 6:24 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Rename Sequence.elementsEqual
>
>- Proposal: SE-
>
>- Authors: Xiaodi Wu 
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> 
> Introduction
>
> The current behavior of Sequence.elementsEqual is potentially confusing
> to users given its name. Having surveyed the alternative solutions to this
> problem, it is proposed that the method be renamed to Sequence.
> lexicographicallyEquals.
> 
> Motivation
>
> As outlined by Ole Begemann
> , use of
> Sequence.elementsEqual(_:) can lead to surprising results if the
> sequences compared are unordered:
>
> var set1: Set = Set(1...5)var set2: Set = Set((1...5).reversed())
>
> set1 == set2 // trueset1.elementsEqual(set2) // false
>
> This result does reflect the *intended and documented* behavior of the
> elementsEqual(_:) method, which performs a *lexicographical* elementwise
> comparison. That is, the method first compares set1.first to set2.first,
> then (if the two elements compare equal) compares the next element stored
> internally in set1 to the next element stored internally in set2, and so
> on.
>
> In almost all circumstances where a set is compared to another set, or a
> dictionary is compared to another dictionary, users should use == instead
> of elementsEqual(_:).
>
> Proposed
> solution
>
> The proposed solution is the result of an iterative process of reasoning,
> presented here:
>
> The first and most obvious solution is to remove the elementsEqual(_:)
> method altogether in favor of ==. This prevents its misuse. However,
> because elementsEqual(_:) is a generic method on Sequence, we can use it
> to compare an instance of UnsafeBufferPointer to an instance of [Int].
> This is a useful and non-redundant feature which would be eliminated if the
> method is removed altogether.
>
> A second solution  is to
> create overloads that forbid the use of the elementsEqual(_:) method
> specifically in non-generic code. This would prevent misuse in non-generic
> code; however, it would also forbid legitimate mixed-type comparisons in
> non-generic code while failing to prevent misuse in generic code. The
> solution also creates a difference in the behavior of generic and
> non-generic code calling the same method, which is potentially confusing,
> without solving the problem completely.
>
> A third solution is to dramatically overhaul the protocol hierarchy for
> Swift sequences and collections so that unordered collections no longer
> have members such as first and elementsEqual(_:). However, this would be
> a colossal and source-breaking undertaking, and it is unlikely to be
> satisfactory in addressing all the axes of differences among sequence and
> collection types:
>
>- Finite versus infinite
>- Single-pass versus multi-pass
>- Ordered versus unordered
>- Lazy versus eager
>- Forward/bidirectional/random-access
>
> A fourth solution is proposed here. It is predicated on the following
> observation:
>
> *Another method similar to elementsEqual(_:) already exists on Sequence
> named lexicographicallyPrecedes(_:). Like first, elementsEqual(_:),
> drop(while:), and others, it relies on the internal order of elements in a
> manner that is not completely suitable for an unordered collection.
> However, like first and unlike elementsEqual(_:), this fact is called out
> in the name of the method; unsurprisingly, like first and unlike
> elementsEqual(_:), there is no evidence that lexicographicallyPrecedes(_:)
> has been a pitfall for users.*
>
> This observation suggests that a major reason for confusion over
> elementsEqual(_:) stems from its name. So, *it is proposed that
> elementsEqual(_:) should be renamed to lexicographicallyEquals(_:)*. The
> function will remain somewhat of a poor fit for unordered collections, but
> no more so than many other methods that cannot trivially be removed from
> the API of unordered collections (as discussed above). The key is that,
> with such a renaming, the behavior of this method will no longer be
> confusing.
>
> Detailed
> design
>
> extension Sequence where Element : Equatable {
>   @available(*, deprecated, message: "Use '==' if possible to 

Re: [swift-evolution] commas optional

[Kelvin Ma via swift-evolution]

On Thu, Oct 12, 2017 at 6:20 PM, Xiaodi Wu  wrote:

> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I don't really expect this sort of syntactic sugar to be popular enough
>> to make it through swift-evolution, and I don't think it's worth the
>> distraction from more important priorities at this time, but for what it's
>> worth, I've enjoyed this feature in other languages that support it. It
>> plays a small part in making code more focused by eliminating unnecessary
>> syntax.
>>
>> I could be wrong, but I'm not so sure that this would actually be source
>> breaking. Even if you have something like this:
>>
>> let points = [
>> Point(
>> x: 1.0,
>> y: 2.0
>> ),
>> Point(
>> x: 3.0,
>> y: 4.0
>> )
>> ]
>>
>> Proper implementation of this feature wouldn't suddenly interpret
>> `Point(` as its own element.
>>
>
> There are those of us who respect the 80-character line and break
> expressions across lines:
>
> let x = [
>   NSVeryVeryVeryLongType
> .veryVeryVeryLongProperty +
>   NSVeryVeryVeryLongType2
> .veryVeryVeryLongProperty2,
> ]
>
> It would be a pleasant surprise if a grammar with optional commas can
> avoid blowing up existing code; I'm quite doubtful.
>
>
>
An argument against optional commas,, or an indictment of overly verbose
Foundation APIs… 樂樂樂
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Rename Sequence.elementsEqual

[Xiaodi Wu via swift-evolution]

Rename Sequence.elementsEqual

   - Proposal: SE-
   
   - Authors: Xiaodi Wu 
   - Review Manager: TBD
   - Status: *Awaiting review*


Introduction

The current behavior of Sequence.elementsEqual is potentially confusing to
users given its name. Having surveyed the alternative solutions to this
problem, it is proposed that the method be renamed to
Sequence.lexicographicallyEquals.

Motivation

As outlined by Ole Begemann
, use of
Sequence.elementsEqual(_:) can lead to surprising results if the sequences
compared are unordered:

var set1: Set = Set(1...5)var set2: Set = Set((1...5).reversed())

set1 == set2 // trueset1.elementsEqual(set2) // false

This result does reflect the *intended and documented* behavior of the
elementsEqual(_:) method, which performs a *lexicographical* elementwise
comparison. That is, the method first compares set1.first to set2.first,
then (if the two elements compare equal) compares the next element stored
internally in set1 to the next element stored internally in set2, and so on.

In almost all circumstances where a set is compared to another set, or a
dictionary is compared to another dictionary, users should use == instead
of elementsEqual(_:).
Proposed
solution

The proposed solution is the result of an iterative process of reasoning,
presented here:

The first and most obvious solution is to remove the elementsEqual(_:)
method altogether in favor of ==. This prevents its misuse. However,
because elementsEqual(_:) is a generic method on Sequence, we can use it to
compare an instance of UnsafeBufferPointer to an instance of [Int].
This is a useful and non-redundant feature which would be eliminated if the
method is removed altogether.

A second solution  is to create
overloads that forbid the use of the elementsEqual(_:) method specifically
in non-generic code. This would prevent misuse in non-generic code;
however, it would also forbid legitimate mixed-type comparisons in
non-generic code while failing to prevent misuse in generic code. The
solution also creates a difference in the behavior of generic and
non-generic code calling the same method, which is potentially confusing,
without solving the problem completely.

A third solution is to dramatically overhaul the protocol hierarchy for
Swift sequences and collections so that unordered collections no longer
have members such as first and elementsEqual(_:). However, this would be a
colossal and source-breaking undertaking, and it is unlikely to be
satisfactory in addressing all the axes of differences among sequence and
collection types:

   - Finite versus infinite
   - Single-pass versus multi-pass
   - Ordered versus unordered
   - Lazy versus eager
   - Forward/bidirectional/random-access

A fourth solution is proposed here. It is predicated on the following
observation:

*Another method similar to elementsEqual(_:) already exists on Sequence
named lexicographicallyPrecedes(_:). Like first, elementsEqual(_:),
drop(while:), and others, it relies on the internal order of elements in a
manner that is not completely suitable for an unordered collection.
However, like first and unlike elementsEqual(_:), this fact is called out
in the name of the method; unsurprisingly, like first and unlike
elementsEqual(_:), there is no evidence that lexicographicallyPrecedes(_:)
has been a pitfall for users.*

This observation suggests that a major reason for confusion over
elementsEqual(_:) stems from its name. So, *it is proposed that
elementsEqual(_:) should be renamed to lexicographicallyEquals(_:)*. The
function will remain somewhat of a poor fit for unordered collections, but
no more so than many other methods that cannot trivially be removed from
the API of unordered collections (as discussed above). The key is that,
with such a renaming, the behavior of this method will no longer be
confusing.
Detailed
design

extension Sequence where Element : Equatable {
  @available(*, deprecated, message: "Use '==' if possible to compare
two sequences of the same type, or use 'lexicographicallyEquals' to
compare two ordered sequences.")
  public func elementsEqual(
_ other: Other
  ) -> Bool where Other.Element == Element {
return lexicographicallyEquals(other)
  }

  public func lexicographicallyEquals(
_ other: Other
  ) -> Bool where Other.Element == Element {
// The body of this method is unchanged.var iter1 = self.makeIterator()
var iter2 = other.makeIterator()
while true {
  switch (iter1.next(), iter2.next()) {
  

Re: [swift-evolution] commas optional

[Xiaodi Wu via swift-evolution]

On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution <
swift-evolution@swift.org> wrote:

> I don't really expect this sort of syntactic sugar to be popular enough to
> make it through swift-evolution, and I don't think it's worth the
> distraction from more important priorities at this time, but for what it's
> worth, I've enjoyed this feature in other languages that support it. It
> plays a small part in making code more focused by eliminating unnecessary
> syntax.
>
> I could be wrong, but I'm not so sure that this would actually be source
> breaking. Even if you have something like this:
>
> let points = [
> Point(
> x: 1.0,
> y: 2.0
> ),
> Point(
> x: 3.0,
> y: 4.0
> )
> ]
>
> Proper implementation of this feature wouldn't suddenly interpret `Point(`
> as its own element.
>

There are those of us who respect the 80-character line and break
expressions across lines:

let x = [
  NSVeryVeryVeryLongType
.veryVeryVeryLongProperty +
  NSVeryVeryVeryLongType2
.veryVeryVeryLongProperty2,
]

It would be a pleasant surprise if a grammar with optional commas can avoid
blowing up existing code; I'm quite doubtful.


On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution <
> swift-evolution@swift.org>, wrote:
>
>
>
> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> a semicolon is a purely syntactic delimiter, the comma on the other hand
> corresponds to physical elements in a collection. I think the two are more
> different than you suggest.
>
>
> I very much agree^
>
> Josh
>
>
>
> Joshua Parmenter | Engineering Lead, Apple Technologies
>
> T 248 777  <(248)%20777->
> C 206 437 1551 <(206)%20437-1551>
> F 248 616 1980 <(248)%20616-1980>
> www.vectorform.com
> Vectorform
> 2211 5th Ave Suite 201
> Seattle, WA 98121 USA
>
> Think Tank. Lab. Studio.
> We invent digital products and experiences.
>
> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
> ___
> 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

Re: [swift-evolution] commas optional

[Dave Yost via swift-evolution]

> On 2017-10-12, at 12:03 PM, Xiaodi Wu  wrote:
> 
> Single elements can legally span multiple lines; this would be hugely source 
> breaking. What problem are you trying to solve?

The same problem that is solved by the precedent of semicolons being optional 
(clutter). I don’t see anything substantive about the analogy that does not 
hold.

Plus there is the meta-problem of inconsistency, where the analogy is apt but 
not expressed in the language.

> On Thu, Oct 12, 2017 at 13:50 Dave Yost via swift-evolution 
> > wrote:
> 
> Speaking as a huge fan of optional semicolons...
> 
> 
> This seems clear:
> 
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
> 
> and so it occurred to me that this should hold:
> 
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
> 
>   ∴  A comma after the last array element on a line should be optional.
> 
> and these should be legal Swift:
> 
>   let list = [
>   1
>   2
>   ]
> 
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
> 
> equivalent to:
> 
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
> 
> 
> Or, as the Language Reference would say:
> 
> A semicolon (;) can optionally appear after any statement and is used to 
> separate multiple statements if they appear on the same line.
> 
> A comma (,) can optionally appear after any element of an array literal and 
> is used to separate multiple elements if they appear on the same line.
> 
> Or:
> 
> A semicolon (;) separates statements but is optional after the last statement 
> on a line.
> 
> A comma (,) separates elements of an array literal but is optional after the 
> last element on a line.
> 
> 
> ___
> 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

Re: [swift-evolution] commas optional

[Jarod Long via swift-evolution]

I don't really expect this sort of syntactic sugar to be popular enough to make 
it through swift-evolution, and I don't think it's worth the distraction from 
more important priorities at this time, but for what it's worth, I've enjoyed 
this feature in other languages that support it. It plays a small part in 
making code more focused by eliminating unnecessary syntax.

I could be wrong, but I'm not so sure that this would actually be source 
breaking. Even if you have something like this:

let points = [
    Point(
        x: 1.0,
        y: 2.0
    ),
    Point(
        x: 3.0,
        y: 4.0
    )
]

Proper implementation of this feature wouldn't suddenly interpret `Point(` as 
its own element.

Jarod

On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution 
, wrote:
>
>
> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> > wrote:
>
> a semicolon is a purely syntactic delimiter, the comma on the other hand 
> corresponds to physical elements in a collection. I think the two are more 
> different than you suggest.
>
>
> I very much agree^
>
> Josh
>
>
>
> Joshua Parmenter | Engineering Lead, Apple Technologies
>
> T 248 777 
> C 206 437 1551
> F 248 616 1980
> www.vectorform.com
> Vectorform
> 2211 5th Ave Suite 201
> Seattle, WA 98121 USA
>
> Think Tank. Lab. Studio.
> We invent digital products and experiences.
>
> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
> ___
> 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

Re: [swift-evolution] commas optional

[Josh Parmenter via swift-evolution]

On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> wrote:

a semicolon is a purely syntactic delimiter, the comma on the other hand 
corresponds to physical elements in a collection. I think the two are more 
different than you suggest.


I very much agree^

Josh



Joshua Parmenter | Engineering Lead, Apple Technologies

T 248 777 
C 206 437 1551
F 248 616 1980
www.vectorform.com

Vectorform
2211 5th Ave Suite 201
Seattle, WA  98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] commas optional

[Kelvin Ma via swift-evolution]

a semicolon is a purely syntactic delimiter, the comma on the other hand
corresponds to physical elements in a collection. I think the two are more
different than you suggest.

On Thu, Oct 12, 2017 at 1:50 PM, Dave Yost via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Speaking as a huge fan of optional semicolons...
>
>
> This seems clear:
>
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
>
> and so it occurred to me that this should hold:
>
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
>
>   ∴  A comma after the last array element on a line should be optional.
>
> and these should be legal Swift:
>
>   let list = [
>   1
>   2
>   ]
>
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
>
> equivalent to:
>
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
>
>
> Or, as the Language Reference would say:
>
> A semicolon (;) can optionally appear after any statement and is used to
> separate multiple statements if they appear on the same line.
>
>
> A comma (,) can optionally appear after any element of an array literal
> and is used to separate multiple elements if they appear on the same line.
>
>
> Or:
>
> A semicolon (;) separates statements but is optional after the last
> statement on a line.
>
>
> A comma (,) separates elements of an array literal but is optional after
> the last element on a line.
>
>
>
>
> ___
> 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

Re: [swift-evolution] commas optional

[Xiaodi Wu via swift-evolution]

Single elements can legally span multiple lines; this would be hugely
source breaking. What problem are you trying to solve?

On Thu, Oct 12, 2017 at 13:50 Dave Yost via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Speaking as a huge fan of optional semicolons...
>
>
> This seems clear:
>
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
>
> and so it occurred to me that this should hold:
>
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
>
>   ∴  A comma after the last array element on a line should be optional.
>
> and these should be legal Swift:
>
>   let list = [
>   1
>   2
>   ]
>
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
>
> equivalent to:
>
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
>
>
> Or, as the Language Reference would say:
>
> A semicolon (;) can optionally appear after any statement and is used to
> separate multiple statements if they appear on the same line.
>
>
> A comma (,) can optionally appear after any element of an array literal
> and is used to separate multiple elements if they appear on the same line.
>
>
> Or:
>
> A semicolon (;) separates statements but is optional after the last
> statement on a line.
>
>
> A comma (,) separates elements of an array literal but is optional after
> the last element on a line.
>
>
>
> ___
> 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] commas optional

[Dave Yost via swift-evolution]

Speaking as a huge fan of optional semicolons...


This seems clear:

 semicolon : sequence of statements
  :: comma : sequence of elements in an array literal

and so it occurred to me that this should hold:

 A semicolon : the last statement on a line.
  :: A comma : the last array element on a line.

  ∴  A comma after the last array element on a line should be optional.

and these should be legal Swift:

  let list = [
  1
  2
  ]

  let dict = [
  1 : 2
  2 : 3
  ]

equivalent to:

  let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]


Or, as the Language Reference would say:

A semicolon (;) can optionally appear after any statement and is used to 
separate multiple statements if they appear on the same line.

A comma (,) can optionally appear after any element of an array literal and is 
used to separate multiple elements if they appear on the same line.

Or:

A semicolon (;) separates statements but is optional after the last statement 
on a line.

A comma (,) separates elements of an array literal but is optional after the 
last element on a line.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

[Kevin Nattinger via swift-evolution]

> On Oct 12, 2017, at 6:13 AM, Jeremy Pereira  
> wrote:
> 
> 
> 
>> On 11 Oct 2017, at 18:01, Kevin Nattinger  wrote:
>> 
>> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array 
>> (RandomAccessSequence?), they should just be for convenience and with a sane 
>> default RNG*, and users that need more should just use methods on the RNGs 
>> directly.
>> 
>> *: I don't think the default necessarily needs to be a CSRNG; if there's a 
>> fast one, fine. Are we building a padded room for the least competent 
>> engineer or a tool for the average to good engineer to use efficiently?
> 
> I don’t disagree that there should be a *default* RNG. I’m just pointing out 
> that there are advantages to being able to override the default, and Swift 
> has language features that allow you to do so without impacting the 
> simplicity of the default version. I do not understand why, if you are going 
> to have 
> 
>init(randomInRange: Countable{Closed}Range)
> 
> you would be against also having 
> 
>init(randomInRange: Countable{Closed}Range, ing: RNG)
> 
> as well. It’s both convenient and flexible.

My point is that the root method ("designated [not actually an] initializer") 
should be `rngInstance.randomInt()`, so I don't see a reason to also have an 
RNG argument on the convenience `Int.random()`.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

[Mike Kluev via swift-evolution]

On Wed Oct 11 12:21:14 CDT 2017 Cory Benfield cbenfield at apple.com  wrote:
> I strongly recommend building the padded room.

interesting view point.

FTM, the arithmetic operations in swift are "safe and slow" by default,
same principle...
although they are not that slow (compared to how secure random numbers can
be).

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

Did not know you could do that. Still doesn’t change the fundamental
problems with that syntax though. I think that we could enforce a
precondition that overrunning the left hand slice is not allowed, but idk
if subscript notation is worth all that trouble.

On Thu, Oct 12, 2017 at 3:36 AM, Ole Begemann  wrote:

>
> On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky  brackettrozin...@gmail.com> wrote:
>
>> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Yes, a 0-ary operator like that would have to be hard baked into the
>>> language itself.
>>>
>>
>> Actually, you can just make a subscript which takes a function as an
>> argument, and call it by passing in the ellipsis operator.
>>
>
> I mean,,, you can,,, but that’s kind of weird
>
>
> That's exactly how the [...] notation is implemented in the stdlib. Toni
> Suter wrote a great article about it: https://tonisuter.com/
> blog/2017/08/unbounded-ranges-swift-4/
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Property Getter Return Statement

[Goffredo Marocchi via swift-evolution]

Will this finally bring labels back everywhere (closures and stored
functions too)? :D.

On Thu, Oct 12, 2017 at 3:03 PM, Jeremy Pereira via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> >
> > I’m minorly opposed, because it feels like a slippery slope. What about
> function bodies? etc
> >
> > func foo() -> Int { 3 } // should this be allowed?
>
> Yes, why not? What is fundamentally different about a function body
> compared to a getter body (or a closure body ;-)) that means, if we accept
> it for getters, we should not also accept it for function bodies.
>
>
>
> ___
> 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

Re: [swift-evolution] Property Getter Return Statement

[Jeremy Pereira via swift-evolution]

> 
> I’m minorly opposed, because it feels like a slippery slope. What about 
> function bodies? etc
> 
> func foo() -> Int { 3 } // should this be allowed?

Yes, why not? What is fundamentally different about a function body compared to 
a getter body (or a closure body ;-)) that means, if we accept it for getters, 
we should not also accept it for function bodies.



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 12 October 2017 at 14:14, David James  wrote:

> True, and it was making the method signature too long. But at least I have
> the option to do that. If we move the annotation to just before the return
> type, then we have no choice.
>

you can still put it on the next line along with the result :)

imho, this shall not be a decision maker nowadays (20 years ago it would).

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David James via swift-evolution]

> On Oct 12, 2017, at 1:40 PM, Mike Kluev  wrote:
> 
> let me guess: you put it on a different line exactly because it is in it's 
> current ugly form :)


True, and it was making the method signature too long. But at least I have the 
option to do that. If we move the annotation to just before the return type, 
then we have no choice.

David James

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

[Jeremy Pereira via swift-evolution]

> On 11 Oct 2017, at 18:21, Cory Benfield  wrote:
> 
> I strongly recommend building the padded room.
> 

I strongly recommend that the padded room have a door in it.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Random Unification

[Jeremy Pereira via swift-evolution]

> On 11 Oct 2017, at 18:01, Kevin Nattinger  wrote:
> 
> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array 
> (RandomAccessSequence?), they should just be for convenience and with a sane 
> default RNG*, and users that need more should just use methods on the RNGs 
> directly.
> 
> *: I don't think the default necessarily needs to be a CSRNG; if there's a 
> fast one, fine. Are we building a padded room for the least competent 
> engineer or a tool for the average to good engineer to use efficiently?

I don’t disagree that there should be a *default* RNG. I’m just pointing out 
that there are advantages to being able to override the default, and Swift has 
language features that allow you to do so without impacting the simplicity of 
the default version. I do not understand why, if you are going to have 

init(randomInRange: Countable{Closed}Range)

you would be against also having 

init(randomInRange: Countable{Closed}Range, ing: RNG)

as well. It’s both convenient and flexible.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 12 October 2017 at 09:34, David James  wrote:

> IMO everyday app building would rarely need to use functions with
> discardable results. This is more an issue with libraries or frameworks
> that support a *fluent interface* (e.g. that return self) where an
> operator chain can be stopped at any point, unless it clearly doesn’t make
> sense, in which case @discardableResult would not be advised. I am building
> such a library. It has 200+ uses of @discardableResult and *I don’t have
> a problem with it in it’s current form* (especially since it can go on
> the line before the function). It’s an annotation for a specialized
> purpose, hence the very specific nomenclature.
>

let me guess: you put it on a different line exactly because it is in it's
current ugly form :)

personally, if "x: inout Int" is in it's current form (vs. "@inputOutput x:
Int") so shall be "discardable Int", i see no principle difference between
them to make one looking it is from a different planet altogether.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Ole Begemann via swift-evolution]

> On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution 
>  wrote:
> 
> On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky 
> > 
> wrote:
> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution 
> > wrote:
> Yes, a 0-ary operator like that would have to be hard baked into the language 
> itself.
> 
> Actually, you can just make a subscript which takes a function as an 
> argument, and call it by passing in the ellipsis operator.
> 
> I mean,,, you can,,, but that’s kind of weird

That's exactly how the [...] notation is implemented in the stdlib. Toni Suter 
wrote a great article about it: 
https://tonisuter.com/blog/2017/08/unbounded-ranges-swift-4/ 


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David James via swift-evolution]

IMO everyday app building would rarely need to use functions with discardable 
results. This is more an issue with libraries or frameworks that support a 
fluent interface (e.g. that return self) where an operator chain can be stopped 
at any point, unless it clearly doesn’t make sense, in which case 
@discardableResult would not be advised. I am building such a library. It has 
200+ uses of @discardableResult and I don’t have a problem with it in it’s 
current form (especially since it can go on the line before the function). It’s 
an annotation for a specialized purpose, hence the very specific nomenclature.

> On Oct 10, 2017, at 7:48 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> On 10 October 2017 at 07:02, Xiaodi Wu  > wrote:
> This idea was discussed long ago and the present design was selected. At this 
> point in Swift Evolution, source-breaking changes are in scope only if the 
> status quo is demonstrably harmful.
> 
> changes like discussed are not necessarily source-breaking: you can allow 
> @discardableResult for a while (along with deprecating it at some point) in 
> addition to having a newer preferred way - should we decide there is a 
> preferred way.
>  
> on Mon, 09 Oct 2017 20:07:13 +0200 Tino Heth  > wrote:
> As for the line-length, I don’t buy this argument, because placement of line 
> breaks is just personal preference, and keywords/annotations created by 
> gluing together two words should imho avoided wherever possible (not only 
> because the increased character count).
>  
> +1. same here on both counts. multi-word compound and @ symbol makes names 
> ugly. it feels it was done intentionally to indicate a "temporary" "to be 
> cleaned later" nature of a feature (it is a very good choice for @objc)
> 
> and if "fileprivate" is ugly because it is two words glued together (*) maybe 
> there is another name for it? just "file"? "domestic" ?
> 
> Mike
> (* the very concept of "file private" is a bit ugly from a traditional 
> languages perspective).
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

David James

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution