Re: [swift-evolution] Fixed-sized arrays

[Félix Cloutier via swift-evolution]

There have been proposals about that, revolving around creating a new tuple 
syntax for fixed-size arrays, like (Int x 5), and adding a subscript to them. 
IIRC, the sentiment was largely positive but people couldn't agree on the 
specific syntax.

I pushed a little bit for CollectionType on these, regardless of the type 
syntax (could have been (Int, Int, Int, Int, Int) for all I was concerned), but 
there were apparently important implementation challenges stemming from tuples 
being non-nominal types.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009682.html
 


I would like to revive this discussion, but I'm afraid that we're getting late 
for the Swift 3 release.

Félix

> Le 25 juin 2016 à 22:13:43, Daryle Walker via swift-evolution 
>  a écrit :
> 
> [I’ve seen the WWDC 2016 Keynote and State of the Platforms videos.  I 
> haven’t seen any others so I don’t spoil myself before typing my ideas down.  
> Apologies if this has already been covered.]
> 
> Is there any problem to adding fixed-sized arrays?  From what I glanced here, 
> it’s more like no one has gotten around to it and less like the very idea is 
> hated.
> 
> Obviously, the main advantages are that object storage (or pointer storage 
> for reference types) is on the stack and that the shape (i.e. the number of 
> extents and range for each extent) is fixed at compile time.  This type of, 
> well, type can be used when the baggage of length changing isn’t needed  Such 
> arrays are also a classic type since we started system-programming languages. 
>  (I was surprised by their absence in Swift when I first read the books.)  
> They can be mapped to a vector processing unit’s built-ins.
> 
> This:
> 
>> struct ArrayOf5 {
>> 
>> let count = 5
>> 
>> var first: T
>> var second: T
>> var third: T
>> var fourth: T
>> var fifth: T
>> 
>> init(array: [T]) {
>> first = array[0]
>> second = array[1]
>> third = array[2]
>> fourth = array[3]
>> fifth = array[4]
>> }
>> 
>> subscript(index: Int) -> T {
>> get {
>> var preResult: T?
>> switch index {
>> case 0:
>> preResult = first
>> case 1:
>> preResult = second
>> case 2:
>> preResult = third
>> case 3:
>> preResult = fourth
>> case 4:
>> preResult = fifth
>> default:
>> preResult = nil
>> }
>> return preResult!
>> }
>> 
>> set {
>> func doAssign(destination: UnsafeMutablePointer) {
>> destination.memory = newValue
>> }
>> 
>> switch index {
>> case 0:
>> doAssign(&first)
>> case 1:
>> doAssign(&second)
>> case 2:
>> doAssign(&third)
>> case 3:
>> doAssign(&fourth)
>> case 4:
>> doAssign(&fifth)
>> default:
>> doAssign(nil)
>> }
>> }
>> }
>> 
>> }
> 
> 
> shouldn’t be better supported than directly having built-in fixed-sized 
> arrays.  (I’ve wondered if we should have a library or built-in arrays.  I’ve 
> decided that even if we add a library, we still need the built-in.)  Although 
> I parametrized the type, altering the shape (right now 1 dimension of 5 
> elements) doesn’t scale since it requires lexical change.  Internally, a 
> built-in array type would be something like this, modulo optimizations and 
> not having to come up with names for each element.
> 
> —
> 
> [The following sections are my ideas about implementation; we don’t have to 
> use them.]
> 
> What should array type expressions look like in code?
> 
> Since generics (currently) only use type-based parameters, we can’t do 
> something C++-ish like “array”.  I did have a thought of 
> “[MyType; 5]”, but that seemed too close to current arrays.  I was shocked to 
> discover that Rust uses that syntax.  However, it’s still to bad to use now 
> because ‘[MyType]” would mean something different that it does currently 
> (zero-dimensional array of a single unit instead of one-dimensional array of 
> arbitrary number of elements).
> 
> Since arrays are product types (I think), let’s use multiplication syntax:
> 
>> var myArray: MyType * [6]  // This is an array of six elements, each of 
>> `MyType`
>> var myArray2: MyType * [6] * [5]  // This is an array of five elements, each 
>> a six-element array of `MyType`
>> var myArray3: MyType * [3, 4]  // This is an array of three-by-four, each 
>> element of `MyType`
> 
> The “[ SHAPE ]” syntax affects the type expression to its left.  An empty 
> list is not allowed since, although array-literal syntax allows empty lists, 
> t

[swift-evolution] Fixed-sized arrays

[Daryle Walker via swift-evolution]

[I’ve seen the WWDC 2016 Keynote and State of the Platforms videos.  I haven’t 
seen any others so I don’t spoil myself before typing my ideas down.  Apologies 
if this has already been covered.]

Is there any problem to adding fixed-sized arrays?  From what I glanced here, 
it’s more like no one has gotten around to it and less like the very idea is 
hated.

Obviously, the main advantages are that object storage (or pointer storage for 
reference types) is on the stack and that the shape (i.e. the number of extents 
and range for each extent) is fixed at compile time.  This type of, well, type 
can be used when the baggage of length changing isn’t needed  Such arrays are 
also a classic type since we started system-programming languages.  (I was 
surprised by their absence in Swift when I first read the books.)  They can be 
mapped to a vector processing unit’s built-ins.

This:

> struct ArrayOf5 {
> 
> let count = 5
> 
> var first: T
> var second: T
> var third: T
> var fourth: T
> var fifth: T
> 
> init(array: [T]) {
> first = array[0]
> second = array[1]
> third = array[2]
> fourth = array[3]
> fifth = array[4]
> }
> 
> subscript(index: Int) -> T {
> get {
> var preResult: T?
> switch index {
> case 0:
> preResult = first
> case 1:
> preResult = second
> case 2:
> preResult = third
> case 3:
> preResult = fourth
> case 4:
> preResult = fifth
> default:
> preResult = nil
> }
> return preResult!
> }
> 
> set {
> func doAssign(destination: UnsafeMutablePointer) {
> destination.memory = newValue
> }
> 
> switch index {
> case 0:
> doAssign(&first)
> case 1:
> doAssign(&second)
> case 2:
> doAssign(&third)
> case 3:
> doAssign(&fourth)
> case 4:
> doAssign(&fifth)
> default:
> doAssign(nil)
> }
> }
> }
> 
> }


shouldn’t be better supported than directly having built-in fixed-sized arrays. 
 (I’ve wondered if we should have a library or built-in arrays.  I’ve decided 
that even if we add a library, we still need the built-in.)  Although I 
parametrized the type, altering the shape (right now 1 dimension of 5 elements) 
doesn’t scale since it requires lexical change.  Internally, a built-in array 
type would be something like this, modulo optimizations and not having to come 
up with names for each element.

—

[The following sections are my ideas about implementation; we don’t have to use 
them.]

What should array type expressions look like in code?

Since generics (currently) only use type-based parameters, we can’t do 
something C++-ish like “array”.  I did have a thought of “[MyType; 
5]”, but that seemed too close to current arrays.  I was shocked to discover 
that Rust uses that syntax.  However, it’s still to bad to use now because 
‘[MyType]” would mean something different that it does currently 
(zero-dimensional array of a single unit instead of one-dimensional array of 
arbitrary number of elements).

Since arrays are product types (I think), let’s use multiplication syntax:

> var myArray: MyType * [6]  // This is an array of six elements, each of 
> `MyType`
> var myArray2: MyType * [6] * [5]  // This is an array of five elements, each 
> a six-element array of `MyType`
> var myArray3: MyType * [3, 4]  // This is an array of three-by-four, each 
> element of `MyType`

The “[ SHAPE ]” syntax affects the type expression to its left.  An empty list 
is not allowed since, although array-literal syntax allows empty lists, the 
subscript operation does not.  Note, to keep the syntax regular, the first 
subscript when using “myArray2” is for five elements, i.e. “0..<5”, and the 
second (if any) is for six, the reverse lexical order of declaration.  This is 
because we don’t have C’s cute “declaration equals usage” type syntax.  Also 
note that “myArray3” requires a single subscript call with two coordinates in 
it to dereference.  Supplying only one coordinate is nonsensical.  (“myArray2” 
is the other way when you want to dereference a “MyType” value.)

Of course, not using a shape expression gives you a zero-dimensional array 
(i.e. a regular variable) of your base type by default.  (So, it would actually 
be "0 + extents(MyType.self)" dimensions.)

Or we could just do it the same way C does it (i.e. “MyType[8]”), and preserve 
nested arrays having the same lexical order in declaration and dereference.  We 
could even forbid multi-dimensional arrays and just do nested 
single-dimensional arrays like C (and move multi-dimensionality to wrapper 
s

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Erica Sadun via swift-evolution]

On Jun 25, 2016, at 4:25 PM, Dave Abrahams  wrote:
> on Wed Jun 22 2016, Erica Sadun  wrote:
> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution 
>  wrote:
>> 
>> -func forEach(_ body: (S.Iterator.Element) -> ())
>> +func forEach(invoke body: (S.Iterator.Element) -> ())
>> 
>> Adding an external label makes sense here. This is a procedural call and
>> using it within the parens should have a "code ripple".
> 
> I don't think I understand what you mean here.

When using a procedural "trailable" closure inside parentheses, the intention
to do so should be clear:

p(x, perform: {...})
p(x, do: {...})

vs

p(x) {
   ...
}

Anyone reading this code can immediately identify that an otherwise trailing
closure has been pulled inside the signature because the call has become 
significantly more  complex. The point-of-coding decision ripples through
to point-of-reading/point-of-maintenance.

>> That said, would prefer `do` or `perform` over `invoke` or `invoking` as in
>> `runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. 
> 
> Sorry, again, I'm a little lost.  Forgive my overly-literal brain but
> could you please spell out how those latter 3 names relate to the choice
> of `do` or `perform` over `invoke`?   

I read through the pull request. I grouped related modifications
together, although not exhaustively. They fall under the same umbrella, 
choosing `do` or `perform` compared to `invoke` or `invoking`.

-_forAllPermutationsImpl(index + 1, size, &perm, &visited, body)
+_forAllPermutationsImpl(index + 1, size, &perm, &visited, invoke: body)

-public func runRaceTest(trials: Int, threads: Int? = nil, body: () -> ()) {
+public func runRaceTest(
+  trials: Int, threads: Int? = nil, invoking body: () -> ()
+) {

-public func expectFailure(${TRACE}, body: () -> Void) {
+public func expectFailure(${TRACE}, invoking body: () -> Void) {


> 
>> This also applies where there's a `body` label instead of an empty
>> external label.
> 
> We don't have any methods with a `body` label IIUC.

You did, as in the examples just above, which you recommend a rename to 
`invoke` or
`invoking`.

>> -public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {
>> +public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) -> Void) 
>> {
>> 
>> For any with/external label pair, I'd prefer `with-do` or `with-perform` 
>> over `with-invoke`.
> 
> OK.  Is there a rationale, or is it just personal taste?

Strong personal taste, backed by tech writing. Simpler words. 
From the Corpus of Contemporary American English:
do: 18
perform: 955
invoke: does not appear on list.
> 
>> -  return IteratorSequence(it).reduce(initial, combine: f)
>> +  return IteratorSequence(it).reduce(initial, accumulatingBy: f)
>> 
>> For `reduce`, I'd prefer `applying:` or `byApplying:`
> 
> Makes sense.
> 
>> Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,
> 
> I don't see how that works.  You're not comparing the closure with
> anything.

I get your point but I think it's unnecessarily fussy. 

Alternatives are slim on the ground. `usingComparison:` is too long,
as is `byComparingWith:` (which still reads better but you will point
out can be mistaken by some pedant to mean that the sequence is being
compared to the closure), and you won't allow for `comparing:`.
I'm not in love with `comparingWith:` but it reads slightly better to me 
than `comparingBy:`.


> 
>> min/max, byOrdering
> 
> Likewise, you're not ordering the closure.

Same reasoning.

> 
>> -  ).encode(encoding, output: output)
>> +  ).encode(encoding, sendingOutputTo: processCodeUnit)
>> 
>> How about `exportingTo`?
> 
> “export” is freighted with various connotations that I don't think we
> want to make here.  In fact it doesn't mean anything more exotic than
> “sending output to.”

For a language that treasures concision and clarity, this may be clear
but it's notably inconcise. (Yes, that is a new word.)

> 
>> -  tempwords.sort(isOrderedBefore: <)
>> +  tempwords.sort(orderingBy: <)
>> 
>> With `sort` and `sorted`, I'd prefer `by:`
> 
> When people talk about “sorting by XXX”, XXX is a property of the
> elements being sorted.  Therefore IMIO that label should probably be
> reserved for a version that takes a unary projection function:
> 
> friends.sort(by: {$0.lastName})

But they're sorting now, and that feature isn't in Swift.

However, `sorted` falls under another umbrella, which is potential
chaining. In such case, I would prefer there be no internal label at all
to allow cleaner functional flow.

> 
>> -  if !expected.elementsEqual(actual, isEquivalent: sameValue) {
>> +  if !expected.elementsEqual(actual, comparingBy: sameValue) {
>> 
>> I'm torn on this one. I don't like but I don't have a good solution.

I actually meant to move this up to the other discussion of `byComparing` and
forgot to. So please assume you disagree with me on this one too.

>> 
>> -  /// for which `predicate(x) == true`.
>> +

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[David Hart via swift-evolution]

Comments inline:



Sent from my iPhone
> On 26 Jun 2016, at 00:25, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Wed Jun 22 2016, Erica Sadun  wrote:
>> 
>>> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Hi All,
>>> 
>>> A couple of weeks ago we started to notice that we had some poorly-named
>>> closure parameters and argument labels in the standard library, so we
>>> did a complete audit of the standard library's APIs and came up with a
>>> preliminary proposal for changes, which we applied in a branch and you
>>> can review in https://github.com/apple/swift/pull/2981.  Let's please
>>> carry on further discussion here rather than in the pull request, though.
>> 
>> -  /// - `isEquivalent(a, a)` is always `true`. (Reflexivity)
>> -  /// - `isEquivalent(a, b)` implies `isEquivalent(b, a)`. (Symmetry)
>> -  /// - If `isEquivalent(a, b)` and `isEquivalent(b, c)` are both `true`, 
>> then
>> -  ///   `isEquivalent(a, c)` is also `true`. (Transitivity)
>> +  /// - `areEquivalent(a, a)` is always `true`. (Reflexivity)
>> +  /// - `areEquivalent(a, b)` implies `areEquivalent(b, a)`. (Symmetry)
>> +  /// - If `areEquivalent(a, b)` and `areEquivalent(b, c)` are both `true`, 
>> then
>> +  ///   `areEquivalent(a, c)` is also `true`. (Transitivity)
>> 
>> I like this change!
>> 
>> -func forEach(_ body: (S.Iterator.Element) -> ())
>> +func forEach(invoke body: (S.Iterator.Element) -> ())
>> 
>> Adding an external label makes sense here. This is a procedural call and
>> using it within the parens should have a "code ripple".
> 
> I don't think I understand what you mean here.
> 
>> That said, would prefer `do` or `perform` over `invoke` or `invoking` as in
>> `runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. 
> 
> Sorry, again, I'm a little lost.  Forgive my overly-literal brain but
> could you please spell out how those latter 3 names relate to the choice
> of `do` or `perform` over `invoke`?

I'd vote for `do`, just to keep those functional method labels short.

>> This also applies where there's a `body` label instead of an empty
>> external label.
> 
> We don't have any methods with a `body` label IIUC.
> 
>> -public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {
>> +public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) -> Void) 
>> {
>> 
>> For any with/external label pair, I'd prefer `with-do` or `with-perform` 
>> over `with-invoke`.
> 
> OK.  Is there a rationale, or is it just personal taste?
> 
>> -  return IteratorSequence(it).reduce(initial, combine: f)
>> +  return IteratorSequence(it).reduce(initial, accumulatingBy: f)
>> 
>> For `reduce`, I'd prefer `applying:` or `byApplying:`
> 
> Makes sense.

`applying` looks great. The `by` looks redundant in this case.

>> Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,
> 
> I don't see how that works.  You're not comparing the closure with
> anything.
>> min/max, byOrdering
> 
> Likewise, you're not ordering the closure.

I agree with you Dave on both of those.

> 
>> -  ).encode(encoding, output: output)
>> +  ).encode(encoding, sendingOutputTo: processCodeUnit)
>> 
>> How about `exportingTo`?
> 
> “export” is freighted with various connotations that I don't think we
> want to make here.  In fact it doesn't mean anything more exotic than
> “sending output to.”
> 
>> -  tempwords.sort(isOrderedBefore: <)
>> +  tempwords.sort(orderingBy: <)
>> 
>> With `sort` and `sorted`, I'd prefer `by:`
> 
> When people talk about “sorting by XXX”, XXX is a property of the
> elements being sorted.  Therefore IMIO that label should probably be
> reserved for a version that takes a unary projection function:
> 
> friends.sort(by: {$0.lastName})

How about `sort(with:)` then?

> 
>> -  if !expected.elementsEqual(actual, isEquivalent: sameValue) {
>> +  if !expected.elementsEqual(actual, comparingBy: sameValue) {
>> 
>> I'm torn on this one. I don't like but I don't have a good solution.
>> 
>> -  /// for which `predicate(x) == true`.
>> +  /// for which `isIncluded(x) == true`.
>> -  _base: base.makeIterator(), whereElementsSatisfy: _include)
>> +  _base: base.makeIterator(), suchThat: _include)
>> 
>> How about simply `include` for both? 
> 
> Looking at the effect on the doc comments—which is how we should judge
> parameter names—I think `predicate` might read better.
> 
>> I get the `is` desire but it's being tossed away in a lot of other
>> places in this diff. and `suchThat` feels out of place.
> 
> I think I'm pretty strongly sold on “soEach” as a label for closures in
> all the filtering components.
> 
>> -  || u16.contains({ $0 > 127 || _isspace_clocale($0) }) {
>> +|| u16.contains(elementWhere: { $0 > 127 || _isspace_clocale($0) }) {
>> 
>> I assume the challenge here is differentiating contains(element) from 
>> contains(closure).
>> This feels predicate-y, which is why I put it near the predicates. But I 
>> think

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams via swift-evolution]

on Thu Jun 23 2016, Erica Sadun  wrote:

>> On Jun 23, 2016, at 12:39 AM, David Hart  wrote:
>>> -  for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {
>>> +  for test in removeFirstTests.filter(
>>> +suchThat: { $0.numberToRemove == 1 }
>>> 
>>> The difference between `filter` and `forEach` is that `forEach` is 
>>> explicitly 
>>> procedural while `filter` is functional.  I do not like functional chainable
>>> calls being modified to use explicit external labels in this way. 
>>> 
>>> I'd prefer no label here.
>> 
>> Quick aside. Eric, if you prefer no label here, why did you not also
>> prefer no labels for contains and elementsEqual? They also have very
>> functional. But if we must have a label, I’d vote for `where`.
>
> contains and elementsEqual both return Booleans which are almost never 
> chained.

What does chaining have to do with the presence of argument labels?

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

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams via swift-evolution]

on Wed Jun 22 2016, David Hart  wrote:

> I did not pay a lot of attention to this renaming because I thought
> the trailing closure syntax would shield me from labels. But I forgot
> that in if/for/while statements, I’m going to be forced to use
> them. In those cases, I’d prefer more succinct labels.
>
> I added some comments inline where I have issues with the new labels:
>
>> On 23 Jun 2016, at 04:02, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution
>> mailto:swift-evolution@swift.org>>
>> wrote:
>>> 
>>> 
>>> Hi All,
>>> 
>>> A couple of weeks ago we started to notice that we had some poorly-named
>>> closure parameters and argument labels in the standard library, so we
>>> did a complete audit of the standard library's APIs and came up with a
>>> preliminary proposal for changes, which we applied in a branch and you
>>> can review in https://github.com/apple/swift/pull/2981 
>>> .  Let's please
>>> carry on further discussion here rather than in the pull request, though.
>> 
>> -  /// - `isEquivalent(a, a)` is always `true`. (Reflexivity)
>>  -  /// - `isEquivalent(a, b)` implies `isEquivalent(b, a)`. (Symmetry)
>>  -  /// - If `isEquivalent(a, b)` and `isEquivalent(b, c)` are both `true`, 
>> then
>>  -  ///   `isEquivalent(a, c)` is also `true`. (Transitivity)
>>  +  /// - `areEquivalent(a, a)` is always `true`. (Reflexivity)
>>  +  /// - `areEquivalent(a, b)` implies `areEquivalent(b, a)`. (Symmetry)
>>  +  /// - If `areEquivalent(a, b)` and `areEquivalent(b, c)` are both 
>> `true`, then
>>  +  ///   `areEquivalent(a, c)` is also `true`. (Transitivity)
>> 
>> I like this change!
>> 
>> -func forEach(_ body: (S.Iterator.Element) -> ())
>> +func forEach(invoke body: (S.Iterator.Element) -> ())
>> 
>> Adding an external label makes sense here. This is a procedural call and
>> using it within the parens should have a "code ripple".
>> 
>> That said, would prefer `do` or `perform` over `invoke` or `invoking` as in
>> `runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. This also 
>> applies
>> where there's a `body` label instead of an empty external label.
>> 
>> -public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {
>> +public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) -> Void) 
>> {
>> 
>> For any with/external label pair, I'd prefer `with-do` or `with-perform` 
>> over `with-invoke`.
>> 
>> -  return IteratorSequence(it).reduce(initial, combine: f)
>> +  return IteratorSequence(it).reduce(initial, accumulatingBy: f)
>> 
>> For `reduce`, I'd prefer `applying:` or `byApplying:`
>> 
>> Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,
>> min/max, byOrdering
>> 
>> -  ).encode(encoding, output: output)
>> +  ).encode(encoding, sendingOutputTo: processCodeUnit)
>> 
>> How about `exportingTo`?
>
> I know this label does not need to be necessarily short, but I’d
> prefer Erica’s suggestion, or even `to`. encode(a, to: b) reads well
> to me.

Makes sense.

>> -  tempwords.sort(isOrderedBefore: <)
>> +  tempwords.sort(orderingBy: <)
>> 
>> With `sort` and `sorted`, I'd prefer `by:`
>
> I also agree that `by` is more than enough. `sort` already implies an
> `ordering`.

See my reply to Erica.

>> -  if !expected.elementsEqual(actual, isEquivalent: sameValue) {
>> +  if !expected.elementsEqual(actual, comparingBy: sameValue) {
>> 
>> I'm torn on this one. I don't like but I don't have a good solution.
>
> This one has a noticeable chance of appearing in conditional clauses
> so I’d like to go for something short. How about `by`?

You know, it's not bad.  Maybe it's just the fever talking but I am
starting to like these short labels.

>> -  /// for which `predicate(x) == true`.
>> +  /// for which `isIncluded(x) == true`.
>> -  _base: base.makeIterator(), whereElementsSatisfy: _include)
>> +  _base: base.makeIterator(), suchThat: _include)
>> 
>> How about simply `include` for both? I get the `is` desire but it's being 
>> tossed away
>> in a lot of other places in this diff. and `suchThat` feels out of place.
>> 
>> -  || u16.contains({ $0 > 127 || _isspace_clocale($0) }) {
>> +|| u16.contains(elementWhere: { $0 > 127 || _isspace_clocale($0) }) {
>> 
>> I assume the challenge here is differentiating contains(element) from 
>> contains(closure).
>> This feels predicate-y, which is why I put it near the predicates. But I 
>> think something
>> like `containsElement(where:)` works better.
>
> Agreed. Again, same argument. As this is a boolean function, this has
> a higher chance of appearing in conditional clauses so should be
> short. `where` works well for me.

  if friends.contains(where: {$0.firstName == "ted"}) { ... }

?  `contains(where:` doesn't seem very fluent to me.

>>  -let result = try base._withUnsafeMutableBufferPointerIfSupported(body)
>> +let result = try 
>> base._withUnsafeMutableBuf

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams via swift-evolution]

on Wed Jun 22 2016, Erica Sadun  wrote:

> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution 
>  wrote:
>> 
>> 
>> Hi All,
>> 
>> A couple of weeks ago we started to notice that we had some poorly-named
>> closure parameters and argument labels in the standard library, so we
>> did a complete audit of the standard library's APIs and came up with a
>> preliminary proposal for changes, which we applied in a branch and you
>> can review in https://github.com/apple/swift/pull/2981.  Let's please
>> carry on further discussion here rather than in the pull request, though.
>
> -  /// - `isEquivalent(a, a)` is always `true`. (Reflexivity)
>  -  /// - `isEquivalent(a, b)` implies `isEquivalent(b, a)`. (Symmetry)
>  -  /// - If `isEquivalent(a, b)` and `isEquivalent(b, c)` are both `true`, 
> then
>  -  ///   `isEquivalent(a, c)` is also `true`. (Transitivity)
>  +  /// - `areEquivalent(a, a)` is always `true`. (Reflexivity)
>  +  /// - `areEquivalent(a, b)` implies `areEquivalent(b, a)`. (Symmetry)
>  +  /// - If `areEquivalent(a, b)` and `areEquivalent(b, c)` are both `true`, 
> then
>  +  ///   `areEquivalent(a, c)` is also `true`. (Transitivity)
>
> I like this change!
>
> -func forEach(_ body: (S.Iterator.Element) -> ())
> +func forEach(invoke body: (S.Iterator.Element) -> ())
>
> Adding an external label makes sense here. This is a procedural call and
> using it within the parens should have a "code ripple".

I don't think I understand what you mean here.

> That said, would prefer `do` or `perform` over `invoke` or `invoking` as in
> `runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. 

Sorry, again, I'm a little lost.  Forgive my overly-literal brain but
could you please spell out how those latter 3 names relate to the choice
of `do` or `perform` over `invoke`?   

> This also applies where there's a `body` label instead of an empty
> external label.

We don't have any methods with a `body` label IIUC.

> -public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {
> +public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) -> Void) {
>
> For any with/external label pair, I'd prefer `with-do` or `with-perform` 
> over `with-invoke`.

OK.  Is there a rationale, or is it just personal taste?

> -  return IteratorSequence(it).reduce(initial, combine: f)
> +  return IteratorSequence(it).reduce(initial, accumulatingBy: f)
>
> For `reduce`, I'd prefer `applying:` or `byApplying:`

Makes sense.

> Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,

I don't see how that works.  You're not comparing the closure with
anything.

> min/max, byOrdering

Likewise, you're not ordering the closure.

> -  ).encode(encoding, output: output)
> +  ).encode(encoding, sendingOutputTo: processCodeUnit)
>
> How about `exportingTo`?

“export” is freighted with various connotations that I don't think we
want to make here.  In fact it doesn't mean anything more exotic than
“sending output to.”

> -  tempwords.sort(isOrderedBefore: <)
> +  tempwords.sort(orderingBy: <)
>
> With `sort` and `sorted`, I'd prefer `by:`

When people talk about “sorting by XXX”, XXX is a property of the
elements being sorted.  Therefore IMIO that label should probably be
reserved for a version that takes a unary projection function:

 friends.sort(by: {$0.lastName})

> -  if !expected.elementsEqual(actual, isEquivalent: sameValue) {
> +  if !expected.elementsEqual(actual, comparingBy: sameValue) {
>
> I'm torn on this one. I don't like but I don't have a good solution.
>
> -  /// for which `predicate(x) == true`.
> +  /// for which `isIncluded(x) == true`.
> -  _base: base.makeIterator(), whereElementsSatisfy: _include)
> +  _base: base.makeIterator(), suchThat: _include)
>
> How about simply `include` for both? 

Looking at the effect on the doc comments—which is how we should judge
parameter names—I think `predicate` might read better.

> I get the `is` desire but it's being tossed away in a lot of other
> places in this diff. and `suchThat` feels out of place.

I think I'm pretty strongly sold on “soEach” as a label for closures in
all the filtering components.

> -  || u16.contains({ $0 > 127 || _isspace_clocale($0) }) {
> +|| u16.contains(elementWhere: { $0 > 127 || _isspace_clocale($0) }) {
>
> I assume the challenge here is differentiating contains(element) from 
> contains(closure).
> This feels predicate-y, which is why I put it near the predicates. But I 
> think something
> like `containsElement(where:)` works better.

I understand your motivation for suggesting it.  The downside is that it
severs the strong basename relationship between algorithms that do
effectively the same things, one using a default comparison and the
other using an explicitly-specified one.  I'm truly not sure where we
ought to land on this one.

>  -let result = try base._withUnsafeMutableBufferPointerIfSupported(body)
> +let result = try base._withUnsafeMutableBuff

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams via swift-evolution]

on Wed Jun 22 2016, Xiaodi Wu  wrote:

> On Wed, Jun 22, 2016 at 8:12 PM, Sean Heber  wrote:
>
>> How about:
>>
>> let results = possibilities.where(matching: closure)
>>
>
> My understanding is that we're restricting the bikeshedding here to the
> closure label. Renaming `filter` is discussed in another thread, though
> obviously that would change the name of the label as well.

Correct, thanks.

>>
>> :)
>>
>> l8r
>> Sean
>>
>> Sent from my iPad
>>
>> On Jun 22, 2016, at 8:00 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> filter(extractingWhere:)
>> On Wed, Jun 22, 2016 at 18:53 Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> on Wed Jun 22 2016, Xiaodi Wu  wrote:
>>>
>>> > I'll duly oblige with some pushback on `suchThat`. I get that you're
>>> trying
>>> > to clarify whether filter retains or gets rid of elements that match the
>>> > predicate, but I don't think "filter such that" expresses this idea at
>>> all.
>>> >
>>> > Comparing to "filter where," "filter such that" is equally susceptible
>>> to
>>> > misinterpretation that you are filtering to remove elements that are
>>> > matched. For example: "find me some apples, filtering such that are
>>> > bruised."
>>>
>>> Hahaha, that's a very different interpretation of “such” that I hadn't
>>> considered!  OK, suppose it was “soEach:” ?
>>>
>>> let primes = xs.filter(soEach: isPrime)
>>>
>>> > I'd suggest that if you want to be perfectly clear, you'd need something
>>> > like `filter(keepingWhere:)`.
>>>
>>> let primes = xs.filter(keepingWhere: isPrime)
>>>
>>> A slight problem is that filter is nonmutating, so all elements are
>>> “kept.”  But maybe that's just Dave being overly concerned with unlikely
>>> misinterpretations at the cost of “naturalness.”
>>>
>>> Further thoughts?
>>>
>>> > On Wed, Jun 22, 2016 at 18:33 Dave Abrahams via swift-evolution <
>>> > swift-evolution@swift.org> wrote:
>>> >
>>> >>
>>> >> on Tue Jun 21 2016, Dave Abrahams  wrote:
>>> >>
>>> >> > on Mon Jun 20 2016, Brent Royal-Gordon 
>>> >> wrote:
>>> >> >
>>> >> >>> A couple of weeks ago we started to notice that we had some
>>> >> poorly-named
>>> >> >>> closure parameters and argument labels in the standard library, so
>>> we
>>> >> >>> did a complete audit of the standard library's APIs and came up
>>> with a
>>> >> >>> preliminary proposal for changes, which we applied in a branch and
>>> you
>>> >> >>> can review in https://github.com/apple/swift/pull/2981.  Let's
>>> please
>>> >> >>> carry on further discussion here rather than in the pull request,
>>> >> though.
>>> >> >>
>>> >> >> In general, I like this; `orderingBy` is a particularly nice
>>> >> >> improvement over the old `isOrderedBefore` convention.
>>> >> >
>>> >> > I don't really love the use of “by”, FWIW, but I thought
>>> `orderingWith`
>>> >> > was more confusable (ordering A with B might swap A and B, whereas
>>> the
>>> >> > parameter is a closure).  It could be argued, though, that I am being
>>> >> > overly concerned with unlikely misinterpretations, at the cost of
>>> >> > “naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm
>>> open to
>>> >> > discussion on this.
>>> >> >
>>> >> >> A few specific comments about things I don't like:
>>> >> >>
>>> >> >> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
>>> >> >>   over `elementTransform`.
>>> >> >
>>> >> > I think you mean the converse.  And I agree that `elementTransform`
>>> >> > is probably not an improvement over `transform`.
>>> >>
>>> >> ...and I've gone back to `transform` in my PR.
>>> >>
>>> >> >> * In general, I'm not a fan of most of the changes away from `where`
>>> >> >> labels.
>>> >> >
>>> >> > The only such changes I can find are in
>>> >> >
>>> >>
>>> https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106
>>> >> >
>>> >> > Note that part of this change was to make all filter closures
>>> >> > consistent; in the main `filter` API there was no label at all.
>>> >> > However, we felt that there's a real clarity problem with the
>>> polarity
>>> >> > of the argument (we talk about “filtering things out” but the closure
>>> >> > indicates which elements to keep).  And we couldn't find a
>>> “where”-based
>>> >> > name that began to clarify it.
>>> >> >
>>> >> > I will argue that even changing to “suchThat,” as in the PR, does not
>>> >> > sufficiently clarify the closure's polarity, and the only true fix
>>> for
>>> >> > filter is to use a different base name (some have suggested “select,”
>>> >> > and I have other ideas), but that is out of scope for this particular
>>> >> > set of changes.  So if the community is happier with a “where” label
>>> >> > here I can live with it.  I do think “suchThat” is marginally
>>> clearer.
>>> >>
>>> >> I have not received any further pushback on “suchThat,” so I've left it
>>> >> alone.
>>> >>
>>> >> >
>>> >> >> Those are a nice, straightforward convention applie

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 25, 2016, at 8:48 PM, Thorsten Seitz  wrote:
> 
> 
>> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic :
>> 
>> 
>> 
>> Regards
>> (From mobile)
>> 
>>> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> 
>>> Sorry for the late reply — I had hoped to be able to think more deeply 
>>> about various points, 
>>> but I’m going to delay that instead of delaying the reply even more :-)
>>> 
>>> 
 Am 17.06.2016 um 19:04 schrieb Dave Abrahams :
 
 
 on Thu Jun 16 2016, Thorsten Seitz  wrote:
 
>> Am 13.06.2016 um 04:04 schrieb Dave Abrahams :
>> 
>> 
>> on Fri Jun 10 2016, Thorsten Seitz  wrote:
>> 
> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution 
> :
> 
> 
> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution 
> :
>>> 
> 
> on Wed Jun 08 2016, Jordan Rose  wrote:
> 
>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>>>  wrote:
>>> 
>>> 
>>> on Wed Jun 08 2016, Thorsten Seitz
>> 
>>> >> >
>>> wrote:
>>> 
 Ah, thanks, I forgot!  I still consider this a bug, though (will 
 have
 to read up again what the reasons are for that behavior).
>>> 
>>> Yes, but in the case of the issue we're discussing, the choices are:
>>> 
>>> 1. Omit from the existential's API any protocol requirements that 
>>> depend
>>> on Self or associated types, in which case it *can't* conform to
>>> itself because it doesn't fulfill the requirements.
>>> 
>>> 2. Erase type relationships and trap at runtime when they don't 
>>> line up.
>>> 
>>> Matthew has been arguing against #2, but you can't “fix the bug” 
>>> without
>>> it.
>> 
>> #1 has been my preference for a while as well, at least as a starting
>> point.
> 
> I should point out that with the resyntaxing of existentials to
> Any, the idea that Collection's existential doesn't
> conform to Collection becomes far less absurd than it was, so maybe 
> this
> is not so bad.
 
 I think the problem is more that Any does not conform to
 a specific value for a type parameter T: Collection
 
 What I mean by this is that `Collection` denotes a type family, a
 generic parameter `T: Collection` denotes a specific (though
 unknown) member of that type family and `Any` denotes
 the type family again, so there is really no point in writing
 Any IMO.
 The type family cannot conform to T because T is just one fixed member 
 of it.
 It conforms to itself, though, as I can write
 let c1: Any = …
 let c2: Any = c1
 
 That’s why I think that we could just drop Any and simply 
 write Collection.
>>> 
>>> Let me expand that a bit:
>>> 
>>> Actually all this talk about existentials vs. generics or protocols
>>> vs. classes has had me confused somewhat and I think there are still
>>> some misconceptions present on this list sometimes, so I’ll try to
>>> clear them up:
>> 
>> There are several objectively incorrect statements here, and several
>> others with which I disagree.  I was hoping someone else would write
>> this for me, but since the post has such a tone of authority I feel I
>> must respond.
> 
> You are right, the tone of my post was not appropriate, for which I
> want to apologize sincerely.
 
 My fundamental disagreement is with the content, not the tone.
 
> I still believe my statements to be valid, though, and will respond to
> your arguments inline. Please don't get me wrong, I'm not trying to
> have an argument for the argument's sake. All I want is to contribute
> maybe a tiny bit to make Swift even better than it already is, by
> sharing ideas and thoughts not only from me but from the designs of
> other perhaps more obscure programming languages which I happen to
> have stumbled upon in the past (often with much delight).
 
 And I want you to know, even though I disagree with what you've written,
 that I very much appreciate the contribution you're making.
>>> 
>>> Thanks! I’m very glad about that!
>>> 
>>> 
 
>>> (1) misconception: protocols with associated types are somehow very
>>> different from generics
>>> 
>>> I don’t think they are and I will explain why. The only difference is
>>> the way the type parameters are bound: generics use explicit parameter
>>> lists whereas protocols use inheritance. That has some advantages
>>> (think long parameter lists of generics

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Anton Zhilin via swift-evolution]

L. Mihalkovic via swift-evolution  writes:

> Don't you think that for no other reason than completeness it would make 
sense to document the metacircular
> definition I suggested?

Okay, okay, I will.

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

[swift-evolution] BigDecimal functionalities or modulus support for NSDecimalNumber

[Andrea Leganza via swift-evolution]

Hello all,

i was working with huge int numbers (28 digits) due to the developing of an 
algorithm to check the validity of IBAN bank codes (source: 
https://en.wikipedia.org/wiki/International_Bank_Account_Number 
)

The algorithm requests to check the modulus of the 28 digits number with value 
97, the only type which was useful due to the size which can contain was 
NSDecimalNumber 
(https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSDecimalNumber_Class/
 
)
 which doesn’t support modulus

I had to use and external library like this one: 
https://github.com/mkrd/Swift-Big-Integer 
 which supports int and double, 
maybe adding the modulus operation to NSDecimalNumber will be useful for some 
users or creating a framework to manage huge int or double.

if something already exists sorry for the trouble.

best regards. 
eng. Andrea Leganza
—
Docente di Fondamenti di programmazione c/o Istituto Quasar - Roma
Docente di Progettazione di Applicazioni per Dispositivi Mobili c/o Istituto 
Quasar - Roma
Docente di Unity3D c/o Vigamus Academy - Roma
Docente di Programmazione Web c/o ENAIP - Roma
Redattore magazine Io Programmo - ed. Master
Adobe Flex & Air certified
Sun Java 1.6 Certified
EUCIP Core Certified

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

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Remy Demarest via swift-evolution]

We don't seem to have a rounded() function either as part of FloatingPoint, we 
should probably have these methods in the end:

func rounded() -> Self
func rounded(withPrecision: Int) -> Self

Along with the 4 other methods proposed below.

> Le 25 juin 2016 à 11:55, Haravikk via swift-evolution 
>  a écrit :
> 
> 
>> On 25 Jun 2016, at 11:06, Karl via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> floor() and ceil(), exactly like C. ceiling() is more descriptive and is a 
>> mathematical term of art .
>> nextIntegralUp() and nextIntegralDown() are more descriptive still, but 
>> possibly misleading as (4.0).nextIntegralUp() == 4.0
> I'm in favour of these capabilities being there, but in terms of naming I've 
> often wondered why it can't just be part of a rounding group of methods like 
> so:
> 
>   func roundedUp() -> Self { … }
>   func roundedUp(withPrecision:Int) -> Self { … }
>   func roundedDown() -> Self { … }
>   func roundedDown(withPrecision:Int) -> Self { … }
> 
> Since the methods with implied precision of zero are equivalent to floor and 
> ceiling surely? I know floor and ceiling are pretty common terms, but they're 
> just a form rounding when it comes down to it.
> ___
> 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] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Haravikk via swift-evolution]

> On 25 Jun 2016, at 11:06, Karl via swift-evolution 
>  wrote:
> 
> floor() and ceil(), exactly like C. ceiling() is more descriptive and is a 
> mathematical term of art .
> nextIntegralUp() and nextIntegralDown() are more descriptive still, but 
> possibly misleading as (4.0).nextIntegralUp() == 4.0
I'm in favour of these capabilities being there, but in terms of naming I've 
often wondered why it can't just be part of a rounding group of methods like so:

func roundedUp() -> Self { … }
func roundedUp(withPrecision:Int) -> Self { … }
func roundedDown() -> Self { … }
func roundedDown(withPrecision:Int) -> Self { … }

Since the methods with implied precision of zero are equivalent to floor and 
ceiling surely? I know floor and ceiling are pretty common terms, but they're 
just a form rounding when it comes down to it.

smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

[Thorsten Seitz via swift-evolution]

> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic :
> 
> 
> 
> Regards
> (From mobile)
> 
> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> Sorry for the late reply — I had hoped to be able to think more deeply about 
>> various points, 
>> but I’m going to delay that instead of delaying the reply even more :-)
>> 
>> 
>>> Am 17.06.2016 um 19:04 schrieb Dave Abrahams >> >:
>>> 
>>> 
>>> on Thu Jun 16 2016, Thorsten Seitz >> > wrote:
>>> 
> Am 13.06.2016 um 04:04 schrieb Dave Abrahams  >:
> 
> 
> on Fri Jun 10 2016, Thorsten Seitz  > wrote:
> 
>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution 
>>> mailto:swift-evolution@swift.org>>:
>>> 
>>> 
 Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution 
 mailto:swift-evolution@swift.org>>:
>> 
 
 on Wed Jun 08 2016, Jordan Rose >>> > wrote:
 
>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> on Wed Jun 08 2016, Thorsten Seitz
> 
>> mailto:swift-evolution@swift.org>
>> > >>
>> wrote:
>> 
>>> Ah, thanks, I forgot!  I still consider this a bug, though (will 
>>> have
>>> to read up again what the reasons are for that behavior).
>> 
>> Yes, but in the case of the issue we're discussing, the choices are:
>> 
>> 1. Omit from the existential's API any protocol requirements that 
>> depend
>> on Self or associated types, in which case it *can't* conform to
>> itself because it doesn't fulfill the requirements.
>> 
>> 2. Erase type relationships and trap at runtime when they don't line 
>> up.
>> 
>> Matthew has been arguing against #2, but you can't “fix the bug” 
>> without
>> it.
> 
> #1 has been my preference for a while as well, at least as a starting
> point.
 
 I should point out that with the resyntaxing of existentials to
 Any, the idea that Collection's existential doesn't
 conform to Collection becomes far less absurd than it was, so maybe 
 this
 is not so bad.
>>> 
>>> I think the problem is more that Any does not conform to
>>> a specific value for a type parameter T: Collection
>>> 
>>> What I mean by this is that `Collection` denotes a type family, a
>>> generic parameter `T: Collection` denotes a specific (though
>>> unknown) member of that type family and `Any` denotes
>>> the type family again, so there is really no point in writing
>>> Any IMO.
>>> The type family cannot conform to T because T is just one fixed member 
>>> of it.
>>> It conforms to itself, though, as I can write
>>> let c1: Any = …
>>> let c2: Any = c1
>>> 
>>> That’s why I think that we could just drop Any and simply 
>>> write Collection.
>> 
>> Let me expand that a bit:
>> 
>> Actually all this talk about existentials vs. generics or protocols
>> vs. classes has had me confused somewhat and I think there are still
>> some misconceptions present on this list sometimes, so I’ll try to
>> clear them up:
> 
> There are several objectively incorrect statements here, and several
> others with which I disagree.  I was hoping someone else would write
> this for me, but since the post has such a tone of authority I feel I
> must respond.
 
 You are right, the tone of my post was not appropriate, for which I
 want to apologize sincerely.
>>> 
>>> My fundamental disagreement is with the content, not the tone.
>>> 
 I still believe my statements to be valid, though, and will respond to
 your arguments inline. Please don't get me wrong, I'm not trying to
 have an argument for the argument's sake. All I want is to contribute
 maybe a tiny bit to make Swift even better than it already is, by
 sharing ideas and thoughts not only from me but from the designs of
 other perhaps more obscure programming languages which I happen to
 have stumbled upon in the past (often with much delight).
>>> 
>>> And I want you to know, even though I disagree with what you've written,
>>> that I very much appreciate the contribution you're making.
>> 
>> Thanks! I’m very glad about that!
>> 
>> 
>>> 
>> (1) misconception: protocols with associated types are somehow very
>> different from generics
>> 
>> I don’t think they are and I will explain why. The only difference is
>> the way 

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Austin Zheng via swift-evolution]

Hi all,

Thank you for all your comments and feedback! I've rewritten and expanded the 
proposal to address as many peoples' concerns as possible.

Best,
Austin

> On Jun 24, 2016, at 10:50 PM, Austin Zheng  wrote:
> 
> Hello all,
> 
> Per Chris Lattner's list of open Swift 3 design topics 
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 
> ), I've put 
> together a proposal for removing type inference for associated types.
> 
> It can be found here: 
> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
>  
> 
> 
> Thoughts, criticism, and feedback welcome. There are at least two slightly 
> different designs in the proposal, and I'm sure people will have ideas for 
> even more.
> 
> Best,
> Austin

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

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Don't you think that for no other reason than completeness it would make sense 
to document the metacircular definition I suggested? 

> On Jun 25, 2016, at 7:57 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> I replaced `precedencegroup` with `precedence` and added `Precedence` 
> suffix to all precedence group names. See:
> 
> https://github.com/Anton3/swift-evolution/blob/fix-operator-
> precedence/proposals/0077-operator-precedence.md
> 
> My feelings:
> 1. `precedencegroup` describes what it declares more precisely
> 2. `precedence` is shorter (partially compensating for longer names)
> 3. `precedence` can be correctly interpreted as "precedence level"
> 4. `precedence` looks nicer overall
> 
> 5. `Precedence` suffix is bulky. One must specify it in operator 
> declarations and in all relationships
> 6. All groups ending with adjectives may unambiguously drop the suffix
> 7. Number of such groups is small. New groups will tend to be named after 
> corresponding operators, and they will be noun-based
> 
> Questions:
> 1. Where else can we drop -Precedence?
> 2. Can we make more names end with adjectives?
> 
> ___
> 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] [Returned for revision] SE-0077: Improved operator declarations

[Anton Zhilin via swift-evolution]

I replaced `precedencegroup` with `precedence` and added `Precedence` 
suffix to all precedence group names. See:

https://github.com/Anton3/swift-evolution/blob/fix-operator-
precedence/proposals/0077-operator-precedence.md

My feelings:
1. `precedencegroup` describes what it declares more precisely
2. `precedence` is shorter (partially compensating for longer names)
3. `precedence` can be correctly interpreted as "precedence level"
4. `precedence` looks nicer overall

5. `Precedence` suffix is bulky. One must specify it in operator 
declarations and in all relationships
6. All groups ending with adjectives may unambiguously drop the suffix
7. Number of such groups is small. New groups will tend to be named after 
corresponding operators, and they will be noun-based

Questions:
1. Where else can we drop -Precedence?
2. Can we make more names end with adjectives?

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Austin Zheng via swift-evolution]

> On Jun 25, 2016, at 6:23 AM, Matthew Johnson  wrote:
> 
> Hi Austin,
> 
> I’m sorry to say, but this proposal makes me really sad.  I consider 
> associated type inference one of the more elegant aspects of Swift.  It would 
> be very unfortunate to lose it.  

There are lots of "elegant" things that Swift could do, but has chosen not to 
do for pragmatic reasons (e.g. generalized implicit conversions, type inference 
that crosses statement boundaries). Given how terrible the development 
experience can be right now in the worst case, I would happily trade off some 
measure of convenience for better tooling.

> 
> I am really pleased to see that Dmitri has offered an alternative that looks 
> very reasonable.  I’m hoping the Doug or Chris (or someone else from the core 
> team) can chime in on the feasibility of this alternative.  If it is 
> considered viable and Dmitri isn’t able to write the proposal I would be 
> happy to do so.
> 
> If the alternative isn’t viable and we must proceed with a proposal to remove 
> inference I think there is one crucial thing to consider that isn’t discussed 
> in this proposal: retroactive modeling.  As far as I can tell, this proposal 
> will *prohibit* some types from conforming to some protocols.  Specifically, 
> if a type defines a typealias with a name that matches the name of an 
> associatedtype in a protocol it would not be possible to retroactively model 
> that protocol.  Because of the name conflict an associatedtype declaration 
> would not be allowed and the existing typealias would not meet the 
> requirement.  Consider this example:

I actually think that the delineation between `associatedtype` and `typealias` 
should make this legal, and will change the proposal as such. It should be 
legal to bind an associated type to a type alias, and it should be possible to 
define a type alias that shadows (but does not conflict with) an associated 
type definition. This would fix the issue with retroactive modeling.

> 
> // Module A
> public struct S {
> public typealias Foo = Int
> }
> 
> // Module B
> public protocol P {
> associatedtype Foo
> }
> 
> // Module C
> import A
> import B
> 
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
> // compiler error: cannot define associatedtype `Foo` for `S` which 
> already declares typealias `Foo`
> associatedtype Foo = String
> }
> 
> I cannot support any proposal that breaks retroactive modeling in this way.

Addendum aside, retroactive modeling is already suboptimal or broken in 
multiple ways today - try conforming a protocol with associated type 'Element' 
to a different protocol whose 'Element' means something completely different.

> 
> Another item that is not mentioned in this proposal is that typealias is not 
> the only way to meet an associatedtype requirement in the language today.  
> For example, this code is legal:
> 
> protocol Foo {
> associatedtype Bar
> }
> struct S : Foo {
> struct Bar {}
> }

I don't see how this is relevant.

struct S : Foo {
  associatedtype S = Bar
  struct Bar { }
}

> 
> If we *must* drop inference I prefer the alternative of just doing that: 
> dropping inference, but otherwise leaving things alone.  All associated type 
> requirements would need to be explicitly satisfied using one of the 
> mechanisms that is currently valid for satisfying a non-inferred associated 
> type requirement.  The ability to satisfy these requirements in a variety of 
> ways is a *benefit* that provides valuable flexibility.

I disagree that it's a benefit. It certainly saves a couple of keystrokes, but 
you gain or lose no expressive power from this proposal, addendum included. I'm 
happy to expand the alternatives section to discuss the other ways to satisfy 
associated type requirements, though.

> 
> I agree that something should look for a good solution to the subclass 
> typealias issue, but I don’t think this is it.  Ideally we would find a 
> solution that works well in the presence of retroactive modeling making code 
> such as the following valid:
> 
> // module A
> protocol P1 {
> associatedtype Foo
> 
>@infers(Foo)
> var foo: Foo { get }
> }
> // module B
> protocol P2 {
> associatedtype Foo
> 
> @infers(Foo)
> func bar() -> Foo
> }
> 
> // module C
> class Base {
> let foo: String = "foo"
> }
> class Derived : Base {
> func bar() -> Int { return 42 }
> }
> 
> // module D
> import A
> import B
> import C
> import D
> extension Base : P1 {}
> extension Derived : P2 {}
> 
> We don’t always control the protocol or type definitions we want to make work 
> together.  The ability to make code that “should work together” actually do 
> so with minimal fuss is one of the great things about Swift.  Any time we 
> interfere with retroactive modeling we increase the need for boilerplate 
> adapter types, etc.
> 
> One detail appears to be implied by the proposal but isn’t explicitly stated.

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Austin Zheng via swift-evolution]

Hi Dmitri,

Thanks for bringing this up. I surmise this option involves a user optionally 
marking a specific requirement in a protocol as being "chosen" to bind one or 
more associated types, with other requirements being forced to defer to that 
@infers-marked requirement.

I don't think there should be any problematic corner cases - either way, the 
set of associated types belonging to a type need to be solved in a consistent 
way, and the main difference would be the type of error emitted if the 
associated types could not be determined (e.g. "Associated type 'C' is inferred 
to be 'Int' by the declaration of 'foo(a:)' at line 1234, but was redefined as 
'String' at line 1239").

I will add it to the alternatives section. The core team seems to be quite good 
about picking and choosing whatever they feel are the best parts of whatever 
alternatives are listed, so I think they will consider it very carefully.

Best,
Austin

> On Jun 25, 2016, at 12:51 AM, Dmitri Gribenko  wrote:
> 
> On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution
>  wrote:
>> Hello all,
>> 
>> Per Chris Lattner's list of open Swift 3 design topics
>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put
>> together a proposal for removing type inference for associated types.
> 
> Hi Austin,
> 
> Thank you for starting this discussion!  There's one other alternative
> that I mentioned in one of the previous threads on this subject.  The
> idea is to limit the inference so that the sizes and the complexity of
> the problems that the type checker has to solve become tractable with
> a simple algorithm, not a full constrain solver.
> 
> Currently, as far as I understand, the type checker solves for all
> associated types for a protocol conformance in a single giant step,
> during which every decision can affect every other decision.  My
> suggestion is that we keep associated type inference for the simple
> cases where it is obvious what the user meant.  The author of the
> protocol would be able to identify these simple cases and define how
> exactly the inference should happen.  For example:
> 
> protocol Collection {
>  associatedtype Index
> 
>  @infers(Index)
>  var startIndex: Index
> 
>  // Does not affect associated type inference, types have to match
> with decisions made by other declarations.
>  var endIndex: Index
> 
>  // Does not affect associated type inference.
>  subscript(i: Index) -> Iterator.Element
> 
>  associatedtype Iterator
> 
>  @infers(Iterator)
>  func iterator() -> Iterator
> }
> 
> Under the current system, every declaration in a conforming type that
> matches a requirement that mentions 'Index' can affect the inference.
> That is, 'Index' is inferred from all declarations in the conforming
> type.   But there is no reason to make it that general -- the protocol
> author knows that 'var startIndex' in the conforming type has be of
> the right type, and there is no reason for other declaration to affect
> the decision about what 'Index' is resolved to.  Under the proposed
> rule, there is at most one declaration that the protocol author is
> allowed to designate with @infers, that is allowed to affect the
> inference.  If there is no @infers for a certain associated type, then
> it is never inferred and should always be specified explicitly.
> 
> This is the basic idea, I'm sure there are corner cases I haven't
> thought about (e.g., how does this interact with constrained
> extension, can we still solve everything with a simple algorithm?)
> But the reason why I'm suggesting this alternative is that I'm
> concerned that in simple cases like inferring the 'Index' and
> 'Iterator' typealiases having to specify them manually is just
> boilerplate, that does not add to clarity, and, I believe, can be
> inferred by the type checker without involving a heavy constrain
> solver.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Austin Rathe via swift-evolution]

+1 to the proposal

On Sat, 25 Jun 2016 at 17:48 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> Sent from my iPhone
> On Jun 25, 2016, at 05:06, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31
>
>
> +1
>
> The only thing I'm worried about is the situation where we have "x = N.M",
> and `x.ceiling` equals maybe "(N+2).0" instead of "(N+1).0" because we ran
> out of precision and can't represent (N+1).0. I'm not sure what the exact
> values are where floats (or doubles) stop having enough precision to
> represent inter-integer values... It might be a moot point.
>
> I'd suggest the functions' descriptions to be changed from
> "[largest|smallest] integral value" to "[largest|smallest] representable
> integral value".
>
> - Dave Sweeris
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Sorry for the late reply — I had hoped to be able to think more deeply about 
> various points, 
> but I’m going to delay that instead of delaying the reply even more :-)
> 
> 
>> Am 17.06.2016 um 19:04 schrieb Dave Abrahams :
>> 
>> 
>> on Thu Jun 16 2016, Thorsten Seitz  wrote:
>> 
 Am 13.06.2016 um 04:04 schrieb Dave Abrahams :
 
 
 on Fri Jun 10 2016, Thorsten Seitz  wrote:
 
>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution 
>>> :
>>> 
>>> 
>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution 
>>> :
> 
>>> 
>>> on Wed Jun 08 2016, Jordan Rose  wrote:
>>> 
> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>  wrote:
> 
> 
> on Wed Jun 08 2016, Thorsten Seitz
 
>  >
> wrote:
> 
>> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>> to read up again what the reasons are for that behavior).
> 
> Yes, but in the case of the issue we're discussing, the choices are:
> 
> 1. Omit from the existential's API any protocol requirements that 
> depend
> on Self or associated types, in which case it *can't* conform to
> itself because it doesn't fulfill the requirements.
> 
> 2. Erase type relationships and trap at runtime when they don't line 
> up.
> 
> Matthew has been arguing against #2, but you can't “fix the bug” 
> without
> it.
 
 #1 has been my preference for a while as well, at least as a starting
 point.
>>> 
>>> I should point out that with the resyntaxing of existentials to
>>> Any, the idea that Collection's existential doesn't
>>> conform to Collection becomes far less absurd than it was, so maybe this
>>> is not so bad.
>> 
>> I think the problem is more that Any does not conform to
>> a specific value for a type parameter T: Collection
>> 
>> What I mean by this is that `Collection` denotes a type family, a
>> generic parameter `T: Collection` denotes a specific (though
>> unknown) member of that type family and `Any` denotes
>> the type family again, so there is really no point in writing
>> Any IMO.
>> The type family cannot conform to T because T is just one fixed member 
>> of it.
>> It conforms to itself, though, as I can write
>> let c1: Any = …
>> let c2: Any = c1
>> 
>> That’s why I think that we could just drop Any and simply 
>> write Collection.
> 
> Let me expand that a bit:
> 
> Actually all this talk about existentials vs. generics or protocols
> vs. classes has had me confused somewhat and I think there are still
> some misconceptions present on this list sometimes, so I’ll try to
> clear them up:
 
 There are several objectively incorrect statements here, and several
 others with which I disagree.  I was hoping someone else would write
 this for me, but since the post has such a tone of authority I feel I
 must respond.
>>> 
>>> You are right, the tone of my post was not appropriate, for which I
>>> want to apologize sincerely.
>> 
>> My fundamental disagreement is with the content, not the tone.
>> 
>>> I still believe my statements to be valid, though, and will respond to
>>> your arguments inline. Please don't get me wrong, I'm not trying to
>>> have an argument for the argument's sake. All I want is to contribute
>>> maybe a tiny bit to make Swift even better than it already is, by
>>> sharing ideas and thoughts not only from me but from the designs of
>>> other perhaps more obscure programming languages which I happen to
>>> have stumbled upon in the past (often with much delight).
>> 
>> And I want you to know, even though I disagree with what you've written,
>> that I very much appreciate the contribution you're making.
> 
> Thanks! I’m very glad about that!
> 
> 
>> 
> (1) misconception: protocols with associated types are somehow very
> different from generics
> 
> I don’t think they are and I will explain why. The only difference is
> the way the type parameters are bound: generics use explicit parameter
> lists whereas protocols use inheritance. That has some advantages
> (think long parameter lists of generics) and some disadvantages.
> These ways are dual in a notation sense: generic types have to have
> all parameters bound whereas protocols cannot bind any of them.
> The „existential“ notation `Any<>` being discussed on this list is
> nothing more than adding the ability to protocols to bind the
> parameters to be used just like Java’s wildcards are adding the
> opposite feature to generics, 

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Jun 25, 2016, at 05:06, Karl via swift-evolution 
>  wrote:
> 
> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31

+1

The only thing I'm worried about is the situation where we have "x = N.M", and 
`x.ceiling` equals maybe "(N+2).0" instead of "(N+1).0" because we ran out of 
precision and can't represent (N+1).0. I'm not sure what the exact values are 
where floats (or doubles) stop having enough precision to represent 
inter-integer values... It might be a moot point.

I'd suggest the functions' descriptions to be changed from "[largest|smallest] 
integral value" to "[largest|smallest] representable integral value".

- Dave Sweeris 

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

[Thorsten Seitz via swift-evolution]

Sorry for the late reply — I had hoped to be able to think more deeply about 
various points, 
but I’m going to delay that instead of delaying the reply even more :-)


> Am 17.06.2016 um 19:04 schrieb Dave Abrahams :
> 
> 
> on Thu Jun 16 2016, Thorsten Seitz  wrote:
> 
>>> Am 13.06.2016 um 04:04 schrieb Dave Abrahams :
>>> 
>>> 
>>> on Fri Jun 10 2016, Thorsten Seitz  wrote:
>>> 
> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution 
> :
> 
> 
>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution 
>> :
 
>> 
>> on Wed Jun 08 2016, Jordan Rose  wrote:
>> 
 On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
  wrote:
 
 
 on Wed Jun 08 2016, Thorsten Seitz
>>> 
 >>> >
 wrote:
 
> Ah, thanks, I forgot!  I still consider this a bug, though (will have
> to read up again what the reasons are for that behavior).
 
 Yes, but in the case of the issue we're discussing, the choices are:
 
 1. Omit from the existential's API any protocol requirements that 
 depend
 on Self or associated types, in which case it *can't* conform to
 itself because it doesn't fulfill the requirements.
 
 2. Erase type relationships and trap at runtime when they don't line 
 up.
 
 Matthew has been arguing against #2, but you can't “fix the bug” 
 without
 it.
>>> 
>>> #1 has been my preference for a while as well, at least as a starting
>>> point.
>> 
>> I should point out that with the resyntaxing of existentials to
>> Any, the idea that Collection's existential doesn't
>> conform to Collection becomes far less absurd than it was, so maybe this
>> is not so bad.
> 
> I think the problem is more that Any does not conform to
> a specific value for a type parameter T: Collection
> 
> What I mean by this is that `Collection` denotes a type family, a
> generic parameter `T: Collection` denotes a specific (though
> unknown) member of that type family and `Any` denotes
> the type family again, so there is really no point in writing
> Any IMO.
> The type family cannot conform to T because T is just one fixed member of 
> it.
> It conforms to itself, though, as I can write
> let c1: Any = …
> let c2: Any = c1
> 
> That’s why I think that we could just drop Any and simply 
> write Collection.
 
 Let me expand that a bit:
 
 Actually all this talk about existentials vs. generics or protocols
 vs. classes has had me confused somewhat and I think there are still
 some misconceptions present on this list sometimes, so I’ll try to
 clear them up:
>>> 
>>> There are several objectively incorrect statements here, and several
>>> others with which I disagree.  I was hoping someone else would write
>>> this for me, but since the post has such a tone of authority I feel I
>>> must respond.
>> 
>> You are right, the tone of my post was not appropriate, for which I
>> want to apologize sincerely.
> 
> My fundamental disagreement is with the content, not the tone.
> 
>> I still believe my statements to be valid, though, and will respond to
>> your arguments inline. Please don't get me wrong, I'm not trying to
>> have an argument for the argument's sake. All I want is to contribute
>> maybe a tiny bit to make Swift even better than it already is, by
>> sharing ideas and thoughts not only from me but from the designs of
>> other perhaps more obscure programming languages which I happen to
>> have stumbled upon in the past (often with much delight).
> 
> And I want you to know, even though I disagree with what you've written,
> that I very much appreciate the contribution you're making.

Thanks! I’m very glad about that!


> 
 (1) misconception: protocols with associated types are somehow very
 different from generics
 
 I don’t think they are and I will explain why. The only difference is
 the way the type parameters are bound: generics use explicit parameter
 lists whereas protocols use inheritance. That has some advantages
 (think long parameter lists of generics) and some disadvantages.
 These ways are dual in a notation sense: generic types have to have
 all parameters bound whereas protocols cannot bind any of them.
 The „existential“ notation `Any<>` being discussed on this list is
 nothing more than adding the ability to protocols to bind the
 parameters to be used just like Java’s wildcards are adding the
 opposite feature to generics, namely not having to bind all
 parameters.
>>> 
>>> Protocols and generics fulfill completely different roles in Swift, and
>>> so, **especially in a language design context like the one we're in
>>> here**, must be thought of different

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Xiaodi Wu via swift-evolution]

Yes!
On Sat, Jun 25, 2016 at 11:33 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> Xiaodi Wu via swift-evolution  writes:
>
> > I mean, we have `protocol IteratorProtocol`, so this is par for the
> course!
> > precedencegroup RangePrecedence { ... }
>
> Brandon sent me a bright idea: we should rename precedencegroup to
> precedence. Compare:
>
> precedence RangePrecedence { ... }
> protocol IteratorProtocol { ... }
>
> This is not totally new, but Precedence suffix and comparison to protocols
> is what makes it shine. Anyone else like the idea?
>
> ___
> 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] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

[Vladimir.S via swift-evolution]

I believe this should be done for Swift 3.0 release as this is a *source 
breaking change* and IMO it is very important to remove the inconsistency 
mentioned below.


We removed tuple splatting on caller side and IMO we must complete this job 
to delete the implicit connection between tuple and list of parameters in 
closures/functions.



Currently we have these "features" :


1. Single tuple as parameter is allowed when list of parameters are required:

let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}

(but this causes crash:
let ft2 : (Int,Int) -> Void = { x in print(x) }
)

Opinion: this should not be allowed. Parameter list is required.
`(Int,Int) -> Void` and `((Int,Int)) -> Void` are two different types.


2. Parameter list in closure is allowed when single tuple parameter is 
required:


typealias IntInt = (Int,Int)
typealias IntIntToVoid = (IntInt) -> Void

let tuple : IntInt = (1,2)

func foo(block: IntIntToVoid) { block(tuple) }

foo { x, y in print(x,y)}
foo { (x, y) in print(x, y)}

Opinion: this should not be allowed. Tuple parameter is required.
`((Int,Int)) -> Void` and `(Int,Int) -> Void` are two different types.
Swift should require this syntax to assign tuple parameter's sub-values to 
variables in closure: `{ ((x, y)) in ..}`



3. Inconsistent (and just wrong) function type when a list of parameters 
required(not tuple) :


typealias t1 = (Int, Int) -> Int // clearly here are list of parameters
typealias t2 = ((Int, Int)) -> Int // clearly here is a tuple parameter

print(t1.self) // Prints ((Int, Int)) -> Int  why?
print(t2.self) // Prints ((Int, Int)) -> Int
print(t1.self == t2.self) // true

Opinion: `(Int,Int) -> Void` and `((Int,Int)) -> Void` should be two 
different separate types that can not be implicitly converted to each 
other. Swift's typesystem should separate these types.



4. If the type is the same, why behavior differs :

let add_list:  (Int, Int) -> Int = (+)
let add_tuple: ((Int, Int)) -> Int = (+)

print(add_list.dynamicType == add_tuple.dynamicType) // true

print( add_list(1,2) )
//print( add_list((1,2)) ) // missing argument for parameter #2 in call

//print( add_tuple(1,2) ) // extra argument in call
print( add_tuple((1,2)) )


Proposal:
===

1. Separate function types with parameter list and a tuple parameter. They 
should be two separate types.


2. Require this syntax to assign tuple parameter's sub-values to variables 
in func/closure: `{ ((x, y)) in ..}`, otherwise (i.e. if `{ (x, y) in ..`) 
treat function/closure as having list of parameters.


3. Disallow implicit conversion between function/closure with a list of 
parameters and function/closure where single tuple is required.
This will stop confusion and make the language consistent how it deal with 
tuples and list of parameters in func/closure.


4. It seems like we should keep the ability to explicitly convert one to 
another as some(many?) code can depend on this current behavior and so we 
need a way to convert old code to new.

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[David Hart via swift-evolution]

Hi Matthew,

I really like this proposal (even outside of its goal to simplify the type 
inference engine). The two other motivations in the proposal make very good 
points which can not be easily dismissed (especially to me as it took me a 
while to understand associated types):
It improves the type system's function as a form of code documentation by 
making it very clear to readers of a type declaration how the type's associated 
types are defined.

It makes it significantly easier for those learning the language to understand 
how associated types work.

I added some more comments inline your email:

> On 25 Jun 2016, at 15:23, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Hi Austin,
> 
> I’m sorry to say, but this proposal makes me really sad.  I consider 
> associated type inference one of the more elegant aspects of Swift.  It would 
> be very unfortunate to lose it.  
> 
> I am really pleased to see that Dmitri has offered an alternative that looks 
> very reasonable.  I’m hoping the Doug or Chris (or someone else from the core 
> team) can chime in on the feasibility of this alternative.  If it is 
> considered viable and Dmitri isn’t able to write the proposal I would be 
> happy to do so.

For me, this solution is worse than the current status quo. A feature 
(inference) which works only in certain cases but not all can be very confusing.

> If the alternative isn’t viable and we must proceed with a proposal to remove 
> inference I think there is one crucial thing to consider that isn’t discussed 
> in this proposal: retroactive modeling.  As far as I can tell, this proposal 
> will *prohibit* some types from conforming to some protocols.  Specifically, 
> if a type defines a typealias with a name that matches the name of an 
> associatedtype in a protocol it would not be possible to retroactively model 
> that protocol.  Because of the name conflict an associatedtype declaration 
> would not be allowed and the existing typealias would not meet the 
> requirement.  Consider this example:
> 
> // Module A
> public struct S {
> public typealias Foo = Int
> }
> 
> // Module B
> public protocol P {
> associatedtype Foo
> }
> 
> // Module C
> import A
> import B
> 
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
> // compiler error: cannot define associatedtype `Foo` for `S` which 
> already declares typealias `Foo`
> associatedtype Foo = String
> }
> 
> I cannot support any proposal that breaks retroactive modeling in this way.

This is noteworthy, but solutions can be found. And we already have the problem 
today:

protocol Foo {
associatedtype Baz : Integer
}

struct Bar {
struct Baz { }
}

There’s no way to make Bar conform to Foo (that I know of).

> Another item that is not mentioned in this proposal is that typealias is not 
> the only way to meet an associatedtype requirement in the language today.  
> For example, this code is legal:
> 
> protocol Foo {
> associatedtype Bar
> }
> struct S : Foo {
> struct Bar {}
> }
> 
> If we *must* drop inference I prefer the alternative of just doing that: 
> dropping inference, but otherwise leaving things alone.  All associated type 
> requirements would need to be explicitly satisfied using one of the 
> mechanisms that is currently valid for satisfying a non-inferred associated 
> type requirement.  The ability to satisfy these requirements in a variety of 
> ways is a *benefit* that provides valuable flexibility.
> 
> I agree that something should look for a good solution to the subclass 
> typealias issue, but I don’t think this is it.  Ideally we would find a 
> solution that works well in the presence of retroactive modeling making code 
> such as the following valid:
> 
> // module A
> protocol P1 {
> associatedtype Foo
> 
>@infers(Foo)
> var foo: Foo { get }
> }
> // module B
> protocol P2 {
> associatedtype Foo
> 
> @infers(Foo)
> func bar() -> Foo
> }
> 
> // module C
> class Base {
> let foo: String = "foo"
> }
> class Derived : Base {
> func bar() -> Int { return 42 }
> }
> 
> // module D
> import A
> import B
> import C
> import D
> extension Base : P1 {}
> extension Derived : P2 {}
> 
> We don’t always control the protocol or type definitions we want to make work 
> together.  The ability to make code that “should work together” actually do 
> so with minimal fuss is one of the great things about Swift.  Any time we 
> interfere with retroactive modeling we increase the need for boilerplate 
> adapter types, etc.
> 
> One detail appears to be implied by the proposal but isn’t explicitly stated. 
>  Specifically, it looks like the intent is that other than only being valid 
> when used to meet a protocol requirement, associatedtype otherwise works like 
> a typealias.  It would be good to have this behavior clarified if the 
> proposal moves forward.

It looks like it, but it makes it clear that its there to satisfy an asso

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Anton Zhilin via swift-evolution]

Xiaodi Wu via swift-evolution  writes:

> I mean, we have `protocol IteratorProtocol`, so this is par for the 
course!
> precedencegroup RangePrecedence { ... }

Brandon sent me a bright idea: we should rename precedencegroup to 
precedence. Compare:

precedence RangePrecedence { ... }
protocol IteratorProtocol { ... }

This is not totally new, but Precedence suffix and comparison to protocols 
is what makes it shine. Anyone else like the idea?

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

[swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Spromicky via swift-evolution]

So, its proposal is dead, or what we must to do to force it to swift-evolution 
repo on GitHub?

> Hello, everyone!
> 
> I wanna propose to you to remove force unwrapping in fuction signature for 
> swift code. That no sense in clear swift code. If we wanna use some optional 
> value as function param, that is not optional, we must unwrap it before 
> function call.
> People who new in swift look at how they old Obj-C code (without nullability 
> modifiers) translate in to swift:
> 
> Obj-C:
> - (void)foo:(NSInteger)bar {
> //...
> }
> 
> Swift transaliton:
> func foo(bar: Int!) {
> //...
> }
> 
> And think that force unwrapping in signature is good practice. And start 
> write functions in clear swift code like this:
> 
> func newFoo(bar: Int!) {
> //...
> }
> 
> and use it like this:
> 
> let bar: Int? = 1
> newFoo(bar)
> 
> And it really work, and they does not think that this can crash in case if 
> `bar` will be `nil`.
> But in clear swift we wanna work with parametrs in function that clearly or 
> optional, or not.
> 
> func newFoo(bar: Int) {
> //...
> }
> 
> or
> 
> func newFoo(bar: Int?) {
> //...
> }
> 
> When we write a new function we know what we need in this case and use 
> optional params or not.
> 
> So my proposal is remove force unwrapping(`!`) from function signatures, 
> cause it have no sense, and that confuse new users.
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Xiaodi Wu via swift-evolution]

I mean, we have `protocol IteratorProtocol`, so this is par for the course!


On Sat, Jun 25, 2016 at 09:46 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> From the rationale follows that by default, we get the following
> precedence group declarations:
>
> precedencegroup RangePrecedence { ... }
>
> Everyone agrees? Any ideas on how to reduce redundancy without adding name
> conflicts?
>
> ___
> 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] [Pitch] Remove type inference for associated types

[L. Mihalkovic via swift-evolution]

Sometimes I get the sense that the pleasure of discussing takes precedence over 
the goal it serves, namely to create a language that will be the most 
attractive it can be within a given complexity budget (meaning a balance 
between the immediate reward of shiny new things and the long term evolvability 
of the compiler). I seem to recall this item coming directly from chris as a 
compiler cleanup task.

> On Jun 25, 2016, at 3:23 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Hi Austin,
> 
> I’m sorry to say, but this proposal makes me really sad.  I consider 
> associated type inference one of the more elegant aspects of Swift.  It would 
> be very unfortunate to lose it.  
> 
> I am really pleased to see that Dmitri has offered an alternative that looks 
> very reasonable.  I’m hoping the Doug or Chris (or someone else from the core 
> team) can chime in on the feasibility of this alternative.  If it is 
> considered viable and Dmitri isn’t able to write the proposal I would be 
> happy to do so.
> 
> If the alternative isn’t viable and we must proceed with a proposal to remove 
> inference I think there is one crucial thing to consider that isn’t discussed 
> in this proposal: retroactive modeling.  As far as I can tell, this proposal 
> will *prohibit* some types from conforming to some protocols.  Specifically, 
> if a type defines a typealias with a name that matches the name of an 
> associatedtype in a protocol it would not be possible to retroactively model 
> that protocol.  Because of the name conflict an associatedtype declaration 
> would not be allowed and the existing typealias would not meet the 
> requirement.  Consider this example:
> 
> // Module A
> public struct S {
> public typealias Foo = Int
> }
> 
> // Module B
> public protocol P {
> associatedtype Foo
> }
> 
> // Module C
> import A
> import B
> 
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
> // compiler error: cannot define associatedtype `Foo` for `S` which 
> already declares typealias `Foo`
> associatedtype Foo = String
> }
> 
> I cannot support any proposal that breaks retroactive modeling in this way.
> 
> Another item that is not mentioned in this proposal is that typealias is not 
> the only way to meet an associatedtype requirement in the language today.  
> For example, this code is legal:
> 
> protocol Foo {
> associatedtype Bar
> }
> struct S : Foo {
> struct Bar {}
> }
> 
> If we *must* drop inference I prefer the alternative of just doing that: 
> dropping inference, but otherwise leaving things alone.  All associated type 
> requirements would need to be explicitly satisfied using one of the 
> mechanisms that is currently valid for satisfying a non-inferred associated 
> type requirement.  The ability to satisfy these requirements in a variety of 
> ways is a *benefit* that provides valuable flexibility.
> 
> I agree that something should look for a good solution to the subclass 
> typealias issue, but I don’t think this is it.  Ideally we would find a 
> solution that works well in the presence of retroactive modeling making code 
> such as the following valid:
> 
> // module A
> protocol P1 {
> associatedtype Foo
> 
>@infers(Foo)
> var foo: Foo { get }
> }
> // module B
> protocol P2 {
> associatedtype Foo
> 
> @infers(Foo)
> func bar() -> Foo
> }
> 
> // module C
> class Base {
> let foo: String = "foo"
> }
> class Derived : Base {
> func bar() -> Int { return 42 }
> }
> 
> // module D
> import A
> import B
> import C
> import D
> extension Base : P1 {}
> extension Derived : P2 {}
> 
> We don’t always control the protocol or type definitions we want to make work 
> together.  The ability to make code that “should work together” actually do 
> so with minimal fuss is one of the great things about Swift.  Any time we 
> interfere with retroactive modeling we increase the need for boilerplate 
> adapter types, etc.
> 
> One detail appears to be implied by the proposal but isn’t explicitly stated. 
>  Specifically, it looks like the intent is that other than only being valid 
> when used to meet a protocol requirement, associatedtype otherwise works like 
> a typealias.  It would be good to have this behavior clarified if the 
> proposal moves forward.
> 
> -Matthew
> 
> 
> 
>> On Jun 25, 2016, at 12:50 AM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> Hello all,
>> 
>> Per Chris Lattner's list of open Swift 3 design topics 
>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put 
>> together a proposal for removing type inference for associated types.
>> 
>> It can be found here: 
>> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
>> 
>> Thoughts, criticism, and feedback welcome. There are at least two slightly 
>> different designs in the proposal, and I'm sure people will have ideas for 
>> even more.
>> 

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Anton Zhilin via swift-evolution]

From the rationale follows that by default, we get the following 
precedence group declarations:

precedencegroup RangePrecedence { ... }

Everyone agrees? Any ideas on how to reduce redundancy without adding name 
conflicts?

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Matthew Johnson via swift-evolution]

Hi Austin,

I’m sorry to say, but this proposal makes me really sad.  I consider associated 
type inference one of the more elegant aspects of Swift.  It would be very 
unfortunate to lose it.  

I am really pleased to see that Dmitri has offered an alternative that looks 
very reasonable.  I’m hoping the Doug or Chris (or someone else from the core 
team) can chime in on the feasibility of this alternative.  If it is considered 
viable and Dmitri isn’t able to write the proposal I would be happy to do so.

If the alternative isn’t viable and we must proceed with a proposal to remove 
inference I think there is one crucial thing to consider that isn’t discussed 
in this proposal: retroactive modeling.  As far as I can tell, this proposal 
will *prohibit* some types from conforming to some protocols.  Specifically, if 
a type defines a typealias with a name that matches the name of an 
associatedtype in a protocol it would not be possible to retroactively model 
that protocol.  Because of the name conflict an associatedtype declaration 
would not be allowed and the existing typealias would not meet the requirement. 
 Consider this example:

// Module A
public struct S {
public typealias Foo = Int
}

// Module B
public protocol P {
associatedtype Foo
}

// Module C
import A
import B

// compiler error: `S` does not meet the `Foo` associatedtype requirement
extension S : P {
// compiler error: cannot define associatedtype `Foo` for `S` which already 
declares typealias `Foo`
associatedtype Foo = String
}

I cannot support any proposal that breaks retroactive modeling in this way.

Another item that is not mentioned in this proposal is that typealias is not 
the only way to meet an associatedtype requirement in the language today.  For 
example, this code is legal:

protocol Foo {
associatedtype Bar
}
struct S : Foo {
struct Bar {}
}

If we *must* drop inference I prefer the alternative of just doing that: 
dropping inference, but otherwise leaving things alone.  All associated type 
requirements would need to be explicitly satisfied using one of the mechanisms 
that is currently valid for satisfying a non-inferred associated type 
requirement.  The ability to satisfy these requirements in a variety of ways is 
a *benefit* that provides valuable flexibility.

I agree that something should look for a good solution to the subclass 
typealias issue, but I don’t think this is it.  Ideally we would find a 
solution that works well in the presence of retroactive modeling making code 
such as the following valid:

// module A
protocol P1 {
associatedtype Foo

   @infers(Foo)
var foo: Foo { get }
}
// module B
protocol P2 {
associatedtype Foo

@infers(Foo)
func bar() -> Foo
}

// module C
class Base {
let foo: String = "foo"
}
class Derived : Base {
func bar() -> Int { return 42 }
}

// module D
import A
import B
import C
import D
extension Base : P1 {}
extension Derived : P2 {}

We don’t always control the protocol or type definitions we want to make work 
together.  The ability to make code that “should work together” actually do so 
with minimal fuss is one of the great things about Swift.  Any time we 
interfere with retroactive modeling we increase the need for boilerplate 
adapter types, etc.

One detail appears to be implied by the proposal but isn’t explicitly stated.  
Specifically, it looks like the intent is that other than only being valid when 
used to meet a protocol requirement, associatedtype otherwise works like a 
typealias.  It would be good to have this behavior clarified if the proposal 
moves forward.

-Matthew



> On Jun 25, 2016, at 12:50 AM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> Per Chris Lattner's list of open Swift 3 design topics 
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 
> ), I've put 
> together a proposal for removing type inference for associated types.
> 
> It can be found here: 
> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
>  
> 
> 
> Thoughts, criticism, and feedback welcome. There are at least two slightly 
> different designs in the proposal, and I'm sure people will have ideas for 
> even more.
> 
> Best,
> Austin
> ___
> 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] [Review] SE-0104: Protocol-oriented integers

[Nicola Salmoria via swift-evolution]

> * What is your evaluation of the proposal?

This is a great proposal which was sorely needed, so I strongly support it
in general. I have a few comments and suggestions to make.


First of all, a bit of background to explain where I'm coming from: in the
past weeks I have been working for educational purposes on a Rational type. This is one of those things that seem trivial at first
sight, but are surprisingly difficult to do right. Thoroughly testing and
avoiding traps or incorrect results in edge cases was a lot of work.
I have now updated my code to use the new interfaces described in the
proposal, and I was able to remove a lot of custom protocols and
boilerplate. So it was a net improvement.


The first comment I have to make is that, as has already been noted by plx,
the Arithmetic protocol looks like a "bag of syntax" with loose semantics
attached. It will be used by signed integers, unsigned integers (naturals),
floating point numbers; and is an obvious conformance for a Rational type as
well.
In the proposal, there is no indication of the expected semantics of the
four basic operations.
- Are addition and multiplication commutative?
- Is multiplication distributive over addition?
- Is 'rhs != 0' a precondition for division?
- Presumably associativity must match the associativity of the operators.
- What is (a / b) * b?
- Is T(exactly: n) * x guaranteed to be == (x + ... + x) n times?

While this protocol is useful to simplify the implementation of operators,
it might be largely superseded by other improvements related to SE-0091.
Taken alone, I'm not sure it pulls its own weight.

For example say I wanted to write some generic code using values that
represent probabilities. I would need arithmetic to work on such values, but
since probabilities are strictly in the interval [0.0, 1.0], integers would
be useless. I could make the code generic over FloatingPoint, but a Rational
type would fit the bill as well, and guarantee accuracy. So to write
meaningful generic code I'd need a different protocol, one that made more
promises about the semantics of division.


Now about the AbsoluteValue associatedtype, which several other people have
already shown doubts about.
I found it useful, precisely for the reason stated in the proposal
(generating the description of a Rational). However, it seems to be mostly
an implementation detail, used to:
1) work around the fact that -Int.min isn't representable in two's complement;
2) provide a way to get the unsigned version of an integer type, to be used
by the doubleWidthMultiply() return type.

These uses suggest that the Integer protocol might not be the best place for
this associatedtype: both of the use cases above would not apply to a
BigInt. It seems more appropriate for it to be part of FixedWidthInteger.
It might even make sense to rename it UnsignedSelf, to make it clear that
it's intended to be the unsigned equivalent of Self.


I also join Karoly's request for double-width division operations. In
particular I would suggest:

static func doubleWidthDivideWithOverflow(_ lhs: (high: Self, low:
AbsoluteValue), by rhs: Self) -> (partialValue: Self, overflow:
ArithmeticOverflow)

static func doubleWidthRemainder(_ lhs: (high: Self, low: AbsoluteValue), by
rhs: Self) -> Self

Note that I needed to use static members here, because the first argument of
the division is not Self. Alternatively, the result of doubleWidthMultiply()
could be a struct, so that double-width division operations could be members
of that struct.

These operations are difficult to implement, and are very useful.

In my specific use case of Rational, addition is the trickiest operation to
implement because it can have transient overflows, which get simplified in
the final result. To handle them, I need to do two double-width multiplies,
followed by a double-width addition (which is easily implemented without
explicit support from the standard library). Then I need a double-width
remainder to compute the GCD, and finally an overflowing double-width
division to attempt fitting the result in a single-width numerator.

Without support for double-width division, the proposal falls short of being
really useful for this kind of operations.


Finally, I don't understand this example, which is also repeated twice in
the proposal. Is it perhaps a copy&paste error?

public struct Int8 {
  public func addingWithOverflow(_ rhs: DoubleWidth)
-> (partialValue: DoubleWidth, overflow: ArithmeticOverflow) {
// efficient implementation
  }
}


> * Is the problem being addressed significant enough to warrant a change to
Swift?

Absolutely. Working with integer types in generic code is currently one of
the most frustrating experiences in Swift. The proposal should address most
of the common issues.

> * Does this proposal fit well with the feel and direction of Swift?

Very well. The new protocols are much more consistent and cohesive than the
status quo.

> * If you have used other languages or libra

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Magnus Ahltorp via swift-evolution]

> 25 June 2016 06:13 Charlie Monroe  wrote:
> 
>> 
>> On Jun 25, 2016, at 12:21 AM, Magnus Ahltorp  wrote:
>> 
>> As far as I can see, forcing the programmer to write identifiers in an 
>> only-ASCII language, and requiring that identifier names have to be 
>> meaningful to the programmer means that the programmer has to know a 
>> language that is written in only ASCII. Most people are not, and requiring 
>> that they first learn for example English to be able to write programs is 
>> absurd.
> 
> You can always write your identifier using ASCII. For languages that use the 
> latin script, just extended with various accents, can be written without them 
> (this is how I was taught). Any language I'm aware of can be eventually 
> written in the latin script (Chinese, cyrilic, ...). 

Take this small example from the Swift book:

let favoriteSnacks = [
"Alice": "Chips",
"Bob": "Licorice",
"Eve": "Pretzels",
]

func buyFavoriteSnack(person: String, vendingMachine: VendingMachine) throws {
let snackName = favoriteSnacks[person] ?? "Candy Bar"
try vendingMachine.vend(itemNamed: snackName)
}

Imagine being forced to write all your identifiers in Chinese script, based on 
the Mandarin transliteration of the English pronunciation:

假设 费弗勒特斯纳克斯 = [
"Alice": "Chips",
"Bob": "Licorice",
"Eve": "Pretzels",
]

函数 拜费弗勒特斯纳克(珀尔瑟恩: 字符串, 文丁默欣: 文丁默欣) 会投掷 {
假设 斯纳克内姆 = 费弗勒特斯纳克斯[珀尔瑟恩] ?? "Candy Bar"
尝试 文丁默欣.文德(艾德姆内姆德: 斯纳克内姆)
}

At least you can write the strings in your familiar script. Since you probably 
don't know Chinese, it is best illustrated by converting it to (non-accented) 
Pinyin.

jiashe feifuletesinakesi = [
"Alice": "Chips",
"Bob": "Licorice",
"Eve": "Pretzels",
]

hanshu baifeifuletesinake(poerseen: zifuchuan, wendingmoxin: wendingmoxin) 
huitouzhi {
jiashe sinakeneimu = feifuletesinakesi[poerseen] ?? "Candy Bar"
changshi wendingmoxin.wende(aidemuneimude: sinakeneimu)
}

You would probably quickly learn words like jiashe and hanshu, but every 
identifier else is actually still in English, just horribly garbled.

Please excuse any errors in the transliterations, but you would probably make 
some errors if you would have to write your code in Chinese as well.

> BTW how far along with programming do you think you'd get without the 
> knowledge of English? All libraries, SDKs use English identifiers. The 
> documentation is in English. For one to lear programming without actually 
> knowing any English would require the language to have localizable 
> identifiers. Can you imagine those? Given how much time is put here to 
> standardize the naming of a few methods in the standard library, how would it 
> look in other languages? 

There are actually programming resources in other languages than English. This 
is especially true for Chinese.

/Magnus

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

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[Haravikk via swift-evolution]

> On 24 Jun 2016, at 23:38, William Jon Shipley  
> wrote:
> 
>> On Jun 24, 2016, at 3:00 PM, Haravikk via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>   for colinearSegment in remainingSegments where 
>> colinearSegment.angle.isEssentially(angle: segment.angle) { // Is parameter 
>> name even necessary?
> 
> My terminology sucks because I don’t remember math terms but basically I’m 
> trying to distinguish between angles of rays (0..<360º) and angles of lines 
> (0..<180º). Because, like, if you have a line at 45º and another at 225º, 
> well, they’re either collinear or parallel.
> 
> So I call the variants “rayAngle:” and “infiniteLineAngle:”. Not my finest 
> hour.

Sorry, I think I got a bit side-tracked, didn't mean to seem too critical of 
the name choice, my point was that the logic is actually pretty 
straightforward, and the line is long because of the verbose naming rather than 
the presence of a where clause (which could also be moved to another line as 
another option). As always you should use whatever names help you to understand 
and remember the intent of the code best, meanwhile I should actually focus on 
what my point was supposed to be =D


So yeah, I don't think any of the examples presented have had "too much logic" 
for a where clause, while more complex cases with ands, ors, etc. might become 
a bit less immediately readable, it's no more so than any other if-condition, 
and it's an issue of personal style choice regardless, rather than a fault with 
a where clause.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Karl via swift-evolution]

Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 


Introduction, Motivation

The standard library lacks equivalents to the floor() and ceil() functions 
found in the standard libraries of most other languages. Currently, we need to 
import Darwin or Glibc in order to access the C standard library versions.

They are essential for many algorithms, and adding them would allow more basic 
algorithms to be written platform-independently (or at least without #if (os) 
flags at the top).

 
Proposed
 Solution

Add floor and ceiling functions (and mutating variants) to FloatingPoint

protocol FloatingPoint {

...

/// Returns the largest integral value not greater than `self`
func floor() -> Self
/// Mutating form of `floor`
mutating func formFloor()

/// Returns the smallest integral value not less than `self`
func ceiling() -> Self
/// Mutating form of `ceiling`
mutating func formCeiling()
}
 
Impact
 on existing code

This change is additive, although we may consider suppressing the imported, 
global-level C functions and automatically migrating them to instance method 
calls.

 
Alternatives
 considered

floor() and ceil(), exactly like C. ceiling() is more descriptive and is a 
mathematical term of art .
nextIntegralUp() and nextIntegralDown() are more descriptive still, but 
possibly misleading as (4.0).nextIntegralUp() == 4.0___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Pyry Jahkola via swift-evolution]

Hi Austin,

I also think it's better to make associated types explicit in protocol 
conformance. But I'm not sure the requirement to use the `associatedtype` 
keyword on the conformance site is the right way to do so, especially since you 
haven't addressed how nested types could fulfill associated type requirements 
in the new design:

extension Foo : P {
struct A { ... }
}

— Pyry

> Austin Zheng wrote:
> 
> Hello all,
> 
> Per Chris Lattner's list of open Swift 3 design topics 
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put 
> together a proposal for removing type inference for associated types.
> 
> It can be found here: 
> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
> 
> Thoughts, criticism, and feedback welcome. There are at least two slightly 
> different designs in the proposal, and I'm sure people will have ideas for 
> even more.
> 
> Best,
> Austin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Revising access modifiers on extensions

[Adrian Zubarev via swift-evolution]

Originally I started this topic in a discussion thread but moved it now into 
its own proposal thread due the lack of feedback.

This proposal contains a breaking change!

You can read a formatted version here: 
https://gist.github.com/DevAndArtist/8f1113b6d5d0379ebf82bd227cf4a88d

Feel free to also provide feedback if you spot any typos or language mistakes I 
might have made.

Revising access modifiers on extensions

Proposal: SE-
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

One great goal for Swift 3 is to sort out any source breaking language changes. 
This proposal aims to fix access modifier inconsistency on extensions compared 
to other scope declarations types.

Swift-evolution thread: [Proposal] Revising access modifiers on extensions

Motivation

When declaring members on extensions which don’t have an explicit access 
modifier in Swift 2.2, it is possible to create an implicitly public extension 
by applying a public modifier to at least one extension member.

public struct A { … }

/* implicitly public */ extension A {
 
public var member1: SomeType { … }
/* implicitly internal */ func member2() { … }
}

/* implicitly internal */ extension A {
 
/* implicitly internal */ var member3: SomeType { … }
}
Furthermore in Swift 2.2 it is not allowed to apply an access modifier on 
extensions when a type inheritance clause is present:

public protocol B { … }

// 'public' modifier cannot be used with
// extensions that declare protocol conformances
public extension A : B { … }
Proposed solution

Allow access modifier on extension when a type inheritance clause is present.

Remove the behavior of an implicit public extension.

This changes should make access modifier on extensions consistent to classes, 
structs and enums (and SE–0025).

The current grammar will not change:

extension-declaration → access-level-modifieropt extension type-identifier 
type-inheritance-clauseopt extension-body

extension-declaration → access-level-modifieropt extension type-identifier 
requirement-clause extension-body

extension-body → { declarationsopt }

Iff the access-level-modifier is not present, the access modifier on extensions 
should always be implicitly internal.

Public Api:

Current version:

//===— Implementation version —===//

public protocol Y {
 
func member()
}

public struct X { … }

/* implicitly public */ extension X : Y {
 
public func member() { … }
 
/* implicitly internal */ func anotherMember() { … }
}

//===— Imported modele version —===//

public protocol Y {
 
func member()
}

public struct X { … }

public extension X : Y {
 
public func member() { … }
}
New Version:

//===— Implementation version —===//

…

public extension X : Y {
 
public func member() { … }
 
/* implicitly internal */ func anotherMember() { … }
}

//===— Imported modele version —===//

…

public extension X : Y {
 
public func member() { … }
}
Impact on existing code

This is a source-breaking change that can be automated by a migrator, by simply 
scanning the extension-body for at least one public modifier on its members. 
Iff a public modifier was found on any member, the migrator can add an explicit 
public modifier to the extension itself.

Alternatives considered

No other alternative were considered for this proposal.
Rationale

On [Date], the core team decided to (TBD) this proposal. When the core team 
makes a decision regarding this proposal, their rationale for the decision will 
be written here.



-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Dmitri Gribenko via swift-evolution]

On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution
 wrote:
> Hello all,
>
> Per Chris Lattner's list of open Swift 3 design topics
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put
> together a proposal for removing type inference for associated types.

Hi Austin,

Thank you for starting this discussion!  There's one other alternative
that I mentioned in one of the previous threads on this subject.  The
idea is to limit the inference so that the sizes and the complexity of
the problems that the type checker has to solve become tractable with
a simple algorithm, not a full constrain solver.

Currently, as far as I understand, the type checker solves for all
associated types for a protocol conformance in a single giant step,
during which every decision can affect every other decision.  My
suggestion is that we keep associated type inference for the simple
cases where it is obvious what the user meant.  The author of the
protocol would be able to identify these simple cases and define how
exactly the inference should happen.  For example:

protocol Collection {
  associatedtype Index

  @infers(Index)
  var startIndex: Index

  // Does not affect associated type inference, types have to match
with decisions made by other declarations.
  var endIndex: Index

  // Does not affect associated type inference.
  subscript(i: Index) -> Iterator.Element

  associatedtype Iterator

  @infers(Iterator)
  func iterator() -> Iterator
}

Under the current system, every declaration in a conforming type that
matches a requirement that mentions 'Index' can affect the inference.
That is, 'Index' is inferred from all declarations in the conforming
type.   But there is no reason to make it that general -- the protocol
author knows that 'var startIndex' in the conforming type has be of
the right type, and there is no reason for other declaration to affect
the decision about what 'Index' is resolved to.  Under the proposed
rule, there is at most one declaration that the protocol author is
allowed to designate with @infers, that is allowed to affect the
inference.  If there is no @infers for a certain associated type, then
it is never inferred and should always be specified explicitly.

This is the basic idea, I'm sure there are corner cases I haven't
thought about (e.g., how does this interact with constrained
extension, can we still solve everything with a simple algorithm?)
But the reason why I'm suggesting this alternative is that I'm
concerned that in simple cases like inferring the 'Index' and
'Iterator' typealiases having to specify them manually is just
boilerplate, that does not add to clarity, and, I believe, can be
inferred by the type checker without involving a heavy constrain
solver.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

> On Jun 25, 2016, at 9:00 AM, L. Mihalkovic  
> wrote:
> 
> Inline
> Regards
> (From mobile)
> 
>> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>>>  ]
>>> 
>>> I’ve gone on record before as against this syntax, although when I set out 
>>> earlier today to record my usual rebuttal I found that it really was mostly 
>>> a matter of taste. Yes, this looks weird to me:
>>> 
>>> let callback: (Data) -> NSCoding & NSCopying
>>> 
>>> but I’m sure the infix ‘->’ for functions looked weird to everyone the 
>>> first time they saw it as well, and it really is pretty clear in argument 
>>> position.
>> 
>> We could conceivably bracket the 'where' constraints somewhere. It's nice 
>> not to have to punish the common case syntax. In my personal ideal vision of 
>> the world, I'd like to see us support opening existentials via 
>> path-dependent types (e.g., let a: Collection; let element: a.Element). If 
>> we support them in decl-level 'where' clauses, we provide a nice, clean 
>> syntax for complex generic relationships that doesn't require angle brackets 
>> or per-existential where clauses at all, something like:
>> 
>>   func intersect(a: Collection, b: Collection) -> Collection
>>   where a.Element == b.Element, b.Element == return.Element {
>>   }
>> 
>> which doesn't completely define away the need for 'where' as part of 
>> existential types, but would shrink it quite a bit.
> 
> For some reason it had not clicked until your 'path dependent type' reference 
> how reminicent of (U+00B7) this is. I watched nada's 2014 presentation 
> again... but then it means intersection types would add a lot... you guys 
> seem ok to add P&Q now, so why not take that opportunity to allow P|Q at the 
> same time. Does it also mean that you might consider at some point expanding 
> 'assoctype U'  into:  T where <:U , :>U  opening the door to lower/higher 
> type bounds?

My point was that the dots (pun intended) are starting to connect and I think 
it is a neat path to follow. Strike union type as the first use case is already 
addressed, and it would no matter what be a larger additive. I would love to 
see a future with type bounds, and although the implementation would be a 
massive delta, the syntax change would be very minimal. I will play more with 
my little syntactic exercise to see what a grammar might look like following 
your train of thoughts.

https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051

>> 
>> -Joe
>> 
>>> However, I did remember one issue, which was brought up on the previous 
>>> mega-thread: if we do want to generalize protocol values, we’re going to 
>>> want something that’s essentially “a type with a ‘where’ clauses in it”. I 
>>> really don’t want to force people to use a typealias to spell such a type, 
>>> but at the same time I want that where clause to be clearly attached to the 
>>> type. (As brought up before the return position of a function is currently 
>>> ambiguous with SE-0081.)
>>> 
>>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>>> against the proposed syntax.
>>> 
>>> Jordan
>>> 
>>> ___
>>> 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] [swift-evolution-announce] [Review] SE-0095: Replace `protocol` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

Inline
Regards
(From mobile)

> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>>  ]
>> 
>> I’ve gone on record before as against this syntax, although when I set out 
>> earlier today to record my usual rebuttal I found that it really was mostly 
>> a matter of taste. Yes, this looks weird to me:
>> 
>> let callback: (Data) -> NSCoding & NSCopying
>> 
>> but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
>> time they saw it as well, and it really is pretty clear in argument position.
> 
> We could conceivably bracket the 'where' constraints somewhere. It's nice not 
> to have to punish the common case syntax. In my personal ideal vision of the 
> world, I'd like to see us support opening existentials via path-dependent 
> types (e.g., let a: Collection; let element: a.Element). If we support them 
> in decl-level 'where' clauses, we provide a nice, clean syntax for complex 
> generic relationships that doesn't require angle brackets or per-existential 
> where clauses at all, something like:
> 
>func intersect(a: Collection, b: Collection) -> Collection
>where a.Element == b.Element, b.Element == return.Element {
>}
> 
> which doesn't completely define away the need for 'where' as part of 
> existential types, but would shrink it quite a bit.

For some reason it had not clicked until your 'path dependent type' reference 
how reminicent of (U+00B7) this is. I watched nada's 2014 presentation again... 
but then it means intersection types would add a lot... you guys seem ok to add 
P&Q now, so why not take that opportunity to allow P|Q at the same time. Does 
it also mean that you might consider at some point expanding 'assoctype U'  
into:  T where <:U , :>U  opening the door to lower/higher type bounds?


> 
> -Joe
> 
>> However, I did remember one issue, which was brought up on the previous 
>> mega-thread: if we do want to generalize protocol values, we’re going to 
>> want something that’s essentially “a type with a ‘where’ clauses in it”. I 
>> really don’t want to force people to use a typealias to spell such a type, 
>> but at the same time I want that where clause to be clearly attached to the 
>> type. (As brought up before the return position of a function is currently 
>> ambiguous with SE-0081.)
>> 
>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>> against the proposed syntax.
>> 
>> Jordan
>> 
>> ___
>> 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