Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Brent Royal-Gordon via swift-evolution]

>>> (tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of 
>>> .next() method for values or .all[] property. Currently we have a problem 
>>> with this.)
>> 
>> There are proposals to do this, but they're on hold at the moment because 
>> the guy who was the main driving force got busy with meatspace things. 
>> Roughly, you would be able to conform an enum to a ValuesEnumerable protocol 
>> which would automatically synthesize an `allValues` static property on it. 
>> You could use an extension to do this to an enum that didn't belong to you, 
>> so you could get this even if the original author didn't think to add it.
>> 
> 
> Could you provide a little more information about this ValuesEnumerable 
> protocol? My Swift says it doesn't know about such protocol.
> Strange, but goggle knows nothing about
> 'swift "ValuesEnumerable"'
> But I can see ValuesEnumerable in some articles related to C#.

This design is still very much under development—it hasn't even been reviewed, 
let alone added to the language. Here's the draft proposal: 


I'm not saying that this will necessarily be a solution that ends up being 
accepted—I'm merely saying that yes, it's something people are thinking about 
and designing; it's just been inactive for a few weeks.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Vladimir.S via swift-evolution]

On 09.04.2016 6:49, Brent Royal-Gordon wrote:

(tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of .next() 
method for values or .all[] property. Currently we have a problem with this.)


There are proposals to do this, but they're on hold at the moment because the 
guy who was the main driving force got busy with meatspace things. Roughly, you 
would be able to conform an enum to a ValuesEnumerable protocol which would 
automatically synthesize an `allValues` static property on it. You could use an 
extension to do this to an enum that didn't belong to you, so you could get 
this even if the original author didn't think to add it.



Could you provide a little more information about this ValuesEnumerable 
protocol? My Swift says it doesn't know about such protocol.

Strange, but goggle knows nothing about
'swift "ValuesEnumerable"'
But I can see ValuesEnumerable in some articles related to C#.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Dietmar Planitzer via swift-evolution]

The biggest missing part with this model is that we are still not able to 
enable macro-level optimizations in the delegating type by checking whether the 
delegate does provide his own implementation of an optional method or doesn’t. 
However, this is an important advantage of the ObjC model that we should not 
lose.

Maybe it’s time to take a big step back and ignore the question of how to 
implement things for a moment and to instead focus on the question of what the 
conceptual differences are between ObjC protocols with optional methods and 
Swift protocols with default implementations. There are two relevant viewpoints 
here:

1) From the viewpoint of a protocol adaptor:

ObjC:

1a) adopter may provide his own implementation of the protocol method, but he 
is no required to.

1b) adopter can see in the protocol declaration for which methods he must 
provide an implementation. Those methods do not have the “optional” keyword in 
front of them while optional methods do.

Swift:

1c) same as (1a).

1d) opening a binary-only Swift file in Xcode with a protocol definition in it 
which contains methods with default implementations will not give any 
indication of which method has a default implementation and which doesn’t. It’s 
only possible to see a difference on the syntax level if you have access to the 
sources.

So from the viewpoint of the protocol adopter, there isn’t much of a 
difference. The only relevant difference is that its always possible in ObjC to 
tell whether a protocol method must be implemented by the adopter or whether a 
method already has a default behavior. We shouldn’t actually have to change 
anything on the syntax-level in Swift to fix this problem. It should be 
sufficient to improve the Swift interface generator in Xcode so that it gives 
an indication whether a protocol method has a default implementation or 
doesn’t. Eg if we want to ensure that the generated interface is valid syntax 
then we could do this:

protocol Foo {

   func void bar() -> Int  /* has default */

}

or if we say that it is fine that the generated interface is not valid syntax 
(I think it already shows "= default” for function arguments with a default 
value which I don’t think is valid syntax), then we could do this:

protocol Foo {

   func void bar() -> Int {…}

}


Now on to the other side of the equation.

2) From the viewpoint of the protocol provider (the person who defines the 
protocol and the type that will invoke the protocol methods):

ObjC:

2a) provider has freedom in deciding where to put the default implementation 
and he can put the default implementation in a single place or spread it out if 
necessary over multiple places. So has the freedom to choose whatever makes the 
most sense for the problem at hand.

2b) provider can detect whether the adopter provides his own protocol method 
implementation without compromising the definition of the protocol 
(compromising here means making return values optional when they should not be 
optional based on the natural definition of the API). This enables the provider 
to implement macro-level optimizations (eg table view can understand whether 
fixed or variable row heights are desired).

Swift:

2c) provider is forced to put the default implementation in a specific place.

2d) provider has no way to detect whether the adopter has provided his own 
implementation of the protocol method.


I do think that (2a) would be nice to have but we can probably do without it if 
it helps us to make progress with this topic. However, the ability to detect 
whether a protocol adopter provides his own implementation of a protocol method 
which comes with a default is a useful and important feature which helps us in 
optimizing the implementation of types and which allows us to keep the API 
surface smaller than it would be without this ability. Just go and compare eg 
UITableView to the Android ListView / RecyclerView to see the consequences of 
not having that ability and how it inflates the API surface (and keep in mind 
that the Android equivalents provide a fraction of the UITableView 
functionality).

The important point about (2b) is actually that we are able to detect whether 
an “override” (I’ll just call this overriding for now) of the default 
implementation exists or does not exist. In ObjC we make this distinction by 
checking whether an implementation of the method exists at all. But we don’t 
have to do it that way. An alternative approach could be based on a check that 
sees whether the dispatch table of the delegate contains a pointer to the 
default implementation of the protocol method or to some other method. So 
conceptually what we want is an operation like this:

func void useDelegate(delegate: NSTableViewDelegate) {

   if has_override(delegate, tableView(_:, heightOfRow:)) {
  // ask the delegate how many rows it has
  // allocate the geometry cache
  // fill in the geometry cache by calling tableView(_:, heightForRow:)

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Wallacy via swift-evolution]

Just as note, i think the sintax should be:

0...9
0..<9
0>..9
0>.<9

Because the intention is produce a number bigger than 0 (start). So greater
than zero less than nine.



Em sex, 8 de abr de 2016 22:50, Michel Fortin via swift-evolution <
swift-evolution@swift.org> escreveu:

> Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> > (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]
>
> The above reads wrong to me. The expression has to be read differently
> depending on the tinny detail that is the sign of the step that comes last:
>
> * positive step: from 0 to 9 striding by 2
> * negative step: to 0 from 9 striding by -2
>
> Am I the only one thinking it's a bit too clever to swap the start and
> stop parts like this?
>
> --
> Michel Fortin
> https://michelf.ca
>
> ___
> 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] [Idea] Find alternatives to `switch self`

[Brent Royal-Gordon via swift-evolution]

> (tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of 
> .next() method for values or .all[] property. Currently we have a problem 
> with this.)

There are proposals to do this, but they're on hold at the moment because the 
guy who was the main driving force got busy with meatspace things. Roughly, you 
would be able to conform an enum to a ValuesEnumerable protocol which would 
automatically synthesize an `allValues` static property on it. You could use an 
extension to do this to an enum that didn't belong to you, so you could get 
this even if the original author didn't think to add it.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Michel Fortin via swift-evolution]

Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution 
 a écrit :
> 
> (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]

The above reads wrong to me. The expression has to be read differently 
depending on the tinny detail that is the sign of the step that comes last:

* positive step: from 0 to 9 striding by 2
* negative step: to 0 from 9 striding by -2

Am I the only one thinking it's a bit too clever to swap the start and stop 
parts like this?

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[Guillaume Lessard via swift-evolution]

Thanks Brent -- I completely agree with your assessment.
I was failing to come up with the proper argument for just about the same idea!

Guillaume Lessard


> On 8 avr. 2016, at 18:32, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> The 'flatten()' method didn't get the Swift 3 API renaming treatment it 
>> should have, to go along with reversed, sorted, joined, etc.
>> As I see Dmitri Gribenko already agree with it but we still have to discuss 
>> it here. So what do you think?
> 
> I'm in favor.
> 
> Though all of these things are terms of art, not all terms of art are created 
> equal. For instance:
> 
> * `map` is supported by virtually any language which have any of these 
> higher-order functions, and to my knowledge the name `map` is universally 
> used.
> * `reduce` is not quite as universally supported, but it's still very common, 
> and most (but not quite all) languages with higher-order functions support it.
> * `filter` is very widely supported, but the *name* `filter` is not quite so 
> consistent. Ruby, for instance, calls it `select`, Perl calls it `grep`, etc.
> * `takeWhile` lies on the other end of the spectrum, being very narrowly 
> supported.
> 
> In my opinion, it would be a really bad idea to rename `map` or `reduce`; 
> `filter` is probably a bad idea but not terrible; but we should feel 
> relatively free to rename `takeWhile`.
> 
> `flatten` is nowhere near as weak a term of art as `takeWhile`, but I think 
> it still falls towards that end of the spectrum. We shouldn't worry too much 
> about changing it. `map`, `reduce`, and `filter` are much stronger terms, and 
> we should be more cautious about changing them.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [SR-933] Rename flatten to flattened

[Brent Royal-Gordon via swift-evolution]

> The 'flatten()' method didn't get the Swift 3 API renaming treatment it 
> should have, to go along with reversed, sorted, joined, etc.
> As I see Dmitri Gribenko already agree with it but we still have to discuss 
> it here. So what do you think?

I'm in favor.

Though all of these things are terms of art, not all terms of art are created 
equal. For instance:

* `map` is supported by virtually any language which have any of these 
higher-order functions, and to my knowledge the name `map` is universally used.
* `reduce` is not quite as universally supported, but it's still very common, 
and most (but not quite all) languages with higher-order functions support it.
* `filter` is very widely supported, but the *name* `filter` is not quite so 
consistent. Ruby, for instance, calls it `select`, Perl calls it `grep`, etc.
* `takeWhile` lies on the other end of the spectrum, being very narrowly 
supported.

In my opinion, it would be a really bad idea to rename `map` or `reduce`; 
`filter` is probably a bad idea but not terrible; but we should feel relatively 
free to rename `takeWhile`.

`flatten` is nowhere near as weak a term of art as `takeWhile`, but I think it 
still falls towards that end of the spectrum. We shouldn't worry too much about 
changing it. `map`, `reduce`, and `filter` are much stronger terms, and we 
should be more cautious about changing them.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Brent Royal-Gordon via swift-evolution]

> We propose to introduce a striding(by:) method on the revised 3.0 Range type.

I take it that we're taking an incremental approach here, and further steps 
like:

* Adding new range operators
* Making all collections Strideable
* Unifying Range and IntervalType so we can stride over non-integers again
* Correctly striding over floats

Are out of scope for this particular proposal.

> (0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 <.. 9).striding(by: 2) ==[2, 4, 6, 8]
> (0 <.< 9).striding(by: 2) ==[2, 4, 6, 8]

I favor `stride(over: 0...9, by: 2)`—or perhaps even `Stride(over: 0...9, by: 
2)`, where `Stride` is a replacement for `StrideTo` and `StrideThrough`—over a 
`striding(by:)` method.  The precedence of the range-construction operators 
makes calling methods on a Range unusually difficult and ugly. (And I don't 
think adjusting the precedence is a realistic option; that would break things 
like `0.. To reverse a stride, call reverse() on the results:
> 
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]

Does this have different behavior from `(0...9).striding(by: -2)`? (I know it 
probably has a different implementation.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

[Jonathan Hull via swift-evolution]

I agree with Brent that there is a larger issue to solve, but I would still 
like to hear your solution, as it may inform the larger solution (and this may 
be a starting point to tackling the whole thing).

The thing that makes the most sense to me, off the top of my head, is to have 
an error that says: “T is ambiguous: Use A.T or B.T to disambiguate.”.  It 
should actually list out the cases if that is technically possible.  I could 
also see the argument that you should always have to specify the protocol (i.e. 
‘A.T' instead of just ’T’) since that would solve post-hoc naming collisions.  
I would also be ok with inferring which protocol T belongs to when it is 
unambiguously possible.


The larger issue is what if protocols A & B both have ‘var t:T’.  The 
interaction of these two problems needs to be considered before we can make 
traction on either.

It seems to me there are two cases for ‘var t:T’: either the T’s are the same 
or they are different.  If they are the same, then everything is ok assuming 
the semantics are also the same, but that is a big assumption.  If the T's are 
different, compliance would require overloading a property, which isn’t 
currently allowed in Swift.  I think there was a proposal to have something 
like ‘var t:T implements A’ and then having the caller disambiguate at the call 
site using ‘(x as A).t’.

It starts to get complex very quickly… (but it is still design work that we 
have to do at some point)

Thanks,
Jon

> Types associated with a protocol are not namespaced by the protocol, but
> rather by the protocol's adopters. As such, when two protocols declare a
> common associatedType, adoption of those protocols introduces undesirable
> ambiguity.
> 
> Given the understandable propensity of developers to arrive at similarly
> named types (T, for example), it is likely that this problem will reduce
> the compatibility of packages for reasons that may not be entirely clear to
> the package consumer.
> 
> Here is a demonstration of the issue. Apologies, I'm a longtime reader of
> the list, but this is my first time posting, and I'm not sure how best to
> format this. You may also find this example on Jira (
> https://bugs.swift.org/browse/SR-1065 
> ).
> 
> ```
> protocol A {
> associatedtype T
> var aT: T { get }
> }
> 
> protocol B {
> associatedtype T
> var bT: T { get }
> }
> ```
> 
> T is ambiguous: "Type C does not conform to protocol 'B'."
> ```
> class C: A, B {
> var aT = String()
> var bT = Int()
> }
> ```
> 
> 
> T is inferred unambiguously, compiles without error.
> ```
> class C: A, B {
> var aT = String()
> var bT = String()
> }
> ```
> 
> T is explicit, but problematic: "Type C does not conform to protocol 'A'."
> ```
> class C: A, B {
> typealias T = Int
> var aT = String()
> var bT = Int()
> }
> ```
> 
> I would greatly appreciate any advice or direction as to next steps. I have
> a proposal for resolving this in mind, but it seemed premature to offer it
> before finding some agreement that this was worth carrying forward.
> 
> Best regards,
> Noah Blake

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

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Taras Zakharko via swift-evolution]

I am agnostic on a .striding() method, but I am strongly agains any suggestions 
of removing/replacing the global stride() function. The stride function does 
not pollute the global namespace as it is a universally useful construct (among 
others, for implementing classical iterating for loops), has its history in 
contemporary programming (comparable functions in languages like Python, R), 
and is IMO more readable and clear than a range with a striding method method. 
Furthermore, a stride is not a range — its a special sequence, while for ranges 
other rules apply. All in all, I don’t see why stride() and .striding() can’t 
coexist. 

— Taras 

P.S. As a side note, I would prefer if the stride() function be renamed 
sequence() or seq(), but thats just cosmetic personal preference. 


> On 08 Apr 2016, at 20:37, Erica Sadun via swift-evolution 
>  wrote:
> 
> Draft here: https://gist.github.com/erica/a51a981ee0352235204692affa959307 
>   Feedback 
> solicited, both positive and negative. 
> We've also got a related proposal about expanding ranges, which you can look 
> at here (https://gist.github.com/erica/af92c541a0fb69fce1b7aaf8374a5aa9 
> )
>  but we want to float this one first.
> 
> Thanks, -- E
> 
> 
> 
> Proposal: SE- 
> 
> Author(s): Xiaodi Wu , Pyry Jahkola 
> , Nate Cook , Erica 
> Sadun 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> We propose to introduce a striding(by:) method on the revised 3.0 Range type.
> 
> This proposal was discussed on the Swift Evolution list in the Feature 
> proposal: Range operator with step 
> 
>  thread. (Direct link 
>  
> to original thread)
> 
>  
> Motivation
> 
> Updating Range for Swift 3 offers a window of opportunity to simultaneously 
> improve strides.
> 
> Under current Swift 3 plans, n.stride(to:/through:, by:) will be replaced 
> with a standalone stride(from:, to:/through:, by:) function. We propose to 
> replace this change with a method on ranges. Using a method reduces overall 
> API surface area compared to free functions.
> 
> In its current incarnation, the standalone stride function uses confusing 
> semantics. The current to implementation returns values in [start, end) and 
> will never reach or get to end. The current through implementation returns 
> values in [start, end]. It may never reach end and certainly never goes 
> through that value. Our proposed method introduces simple, expected semantics 
> that can be extended to both countable and continuous ranges, and to open and 
> closed intervals (both half-open and fully-open).
> 
>  
> Detail
>  Design
> 
> The striding(by:) method is called on ranges. When used with a positive step 
> size, the count starts from the lower bound. With a negative step size, the 
> count starts from the upper bound. These bounds apply regardless of whether 
> they are inclusive or exclusive. 
> 
> The following examples should cover all corner cases and include possible 
> cases should Swift 3 introduce a full complement of open and closed ranges. 
> The syntax for non-canonical range types is not fixed and can be discussed 
> under separate cover.
> 
> (0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
> (0 <.. 9).striding(by: 2) ==[2, 4, 6, 8]
> (0 <.< 9).striding(by: 2) ==[2, 4, 6, 8]
> 
> (0 ... 9).striding(by: 3) == [0, 3, 6, 9]
> (0 ..< 9).striding(by: 3) == [0, 3, 6]
> (0 <.. 9).striding(by: 3) ==[3, 6, 9]
> (0 <.< 9).striding(by: 3) ==[3, 6]
> 
> (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]
> (0 ..< 9).striding(by: -2) ==[7, 5, 3, 1]
> (0 <.. 9).striding(by: -2) == [9, 7, 5, 3, 1]
> (0 <.< 9).striding(by: -2) ==[7, 5, 3, 1]
> 
> (0 ... 9).striding(by: -3) == [9, 6, 3, 0]
> (0 ..< 9).striding(by: -3) ==[6, 3, 0]
> (0 <.. 9).striding(by: -3) == [9, 6, 3]
> (0 <.< 9).striding(by: -3) ==[6, 3]
> To reverse a stride, call reverse() on the results:
> 
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
> We note that striding by 0 should be always be a precondition failure.
> 
>  
> Alternatives
>  Considered
> 
> During the on-list discussion, we considered various scenarios that took 
> closed/i

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Charles Constant via swift-evolution]

Would this still be an issue if switch statements were less verbose? I
don't see why a "switch" statements should be so much more verbose than an
"if statement".

Writing boiler plate for switch statements is by far my #1 irritation at
the moment (now that argument labels have been made beautiful - thanks! -
and Generics are being improved).

As Paul alluded to, this has been discussed with
https://github.com/cacruden/swift-evolution/blob/master/proposals/0024-Pattern-Matching-Partial-Function.md



On Fri, Apr 8, 2016 at 2:30 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> * Allow you to attach member definitions to particular cases. It would be
> an error if they didn't all define the same members, unless there was a
> top-level catchall.
>
>enum Suit: Int {
>var isRed: Bool { return false }
>
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
>
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}
>
>
> Oh my, I absolutely *love this.* This would be a godsend for making
> ErrorType enums that bridge nicely to NSErrors, with code and userInfo
> properties attached to each case.
>
> +1.
>
> Charles
>
>
> ___
> 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] [Idea] Find alternatives to `switch self`

[Charles Srstka via swift-evolution]

> On Mar 23, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> * Allow you to attach member definitions to particular cases. It would be an 
> error if they didn't all define the same members, unless there was a 
> top-level catchall.
> 
>enum Suit: Int {
>var isRed: Bool { return false }
> 
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}

Oh my, I absolutely *love this.* This would be a godsend for making ErrorType 
enums that bridge nicely to NSErrors, with code and userInfo properties 
attached to each case.

+1.

Charles

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

Re: [swift-evolution] [Proposal] Custom operators

[David Waite via swift-evolution]

Based on commit ‘01317e1a’:

I think that it makes sense for membership to live outside of a precedence 
group. An example is if I wanted to add a new assignment operator ( maybe ??= 
'assign if nil’), I would want it to have the same precedence as existing 
assignment operators, including precedence with other custom operators.

Secondly, I think the relationships between precedence groups should be defined 
outside of an existing precedence group. If I have two libraries that declare 
operators in their own custom groups, I may need to define a relationship 
between those groups.

This leads the group declaration itself being just of a name and associativity.

If group precedence is declared externally, there isn’t a need to support ‘>’. 
Since we are declaring a relationship and not evaluating a relationship, there 
are side-effects that developers will need to understand if they are trying to 
comprehend precedence groups in aggregate. Having the groups appear 
consistently in the same order when defining precedence may help with this.

I still assume these relationships are meant to be constrained to a DAG, 
although there might be cases where cycles (or even having multiple graphs) 
would still be unambiguous. I can’t wrap my head around implementation to the 
point of understanding evaluation if not a DAG yet, nor practical reasons to 
have cycles in relations.

Two groups may be unable to be declared to be equivalent. First, they need to 
be of the same associativity. Second are also possibilities of graph cycles 
once the relationships of both groups are overlaid. This is actually the 
trouble I alluded to in my first email in the thread.

Finally, an infix operator is part of one and only one group. It might make 
sense to have a default group (with no associativity) for operators to fall 
into if they do not declare a precedence group.

Oh wait, Yet another quasi-syntax based on the above:

precedencegroup Additive, associativity: left
precedencerelation Additive < Multiplicative
precedencerelation Range < Additive

infix operator +, group: Additive

-DW

> On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution 
>  wrote:
> 
> The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead 
> simple, because if we need to declare precedence group in body of infix 
> operators, then other operators should have it for consistency.
> 
> It's not.
> I suggest an alternative syntax for that:
> infix operator <> : Comparative
> 
> Colon immediately after the operator may not look the best, but it's the only 
> disadvantage I can find. It looks like inheritance and has similar meaning.
> So, in this scheme, all operators will have no body.
> 
> I also described two methods to declare that operator belongs to a precedence 
> group: in `members` and in operator declaration.
> I suggest that this new syntax looks brief/natural enough to remove `members` 
> option entirely. "There should be one - and preferably only one - obvious way 
> to do it."
> 
> - Anton
> 
> 2016-04-08 19:59 GMT+03:00 Антон Жилин  >:
> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was what 
> I needed to do it.
> So, the proposal is now completely overhauled:
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Yes, Maximilian and I have considered operator/precedence groups and they 
> have now moved from alternatives to main part of the proposal.
> 
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that every 
> operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity: left` 
> or `associativity(left)`? So far, only second form has been used somewhere 
> inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
> 
> Just in case, some questions/concerns copied from previous discussion:
> 
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than Comparative 
> or Ternary, or, at least, Assignment.
> 
> 2. Moreover, I could not find any case where I had to write anything other 
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should 
> have less priority than their custom operator.
> 
> But... can you build a custom operator where `<` will actually be needed? I 
> have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or something 
> without losing any expressivity?
> 
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of suc

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Vladimir.S via swift-evolution]

I also agree that there are some problems with enums in current Swift.

(tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of 
.next() method for values or .all[] property. Currently we have a problem 
with this.)


Java's version of enum declaration in this case seems much better IMO. It 
allows to assign additional parameters to "main" enum value in handy way 
and in one place(where the main value itself is declared). In Swift to 
implement the same we have to write these for each param:

   var :  {
   switch self {
   case . : return 
   case . : return 
   case . : return 
   }
   }

Actually, as I understand , we can use custom struct as RawValue to have 
assigned params for each value i.e. something like this:

enum Devices: CGSize {
   case iPhone5 = CGSize(width: 320, height: 568)
   case iPhone6 = CGSize(width: 375, height: 667)
   case iPhone6Plus = CGSize(width: 414, height: 736)
}
and
extension CGSize: StringLiteralConvertible {..}
let a = Devices.iPhone5
let b = a.rawValue
print("string is \(a), width is \(b.width), height is \(b.height)")
(found in Internet)

But personally I don't think this is big problem or if this is totally 
unusable. I think we can live with this.


The real problem is iteration the enum values.

In initial message for this [Idea], in code sample, they use static 
property to be able to iterate enum values - array where all values is stored:

static var all = [ Hearts, Spades, Diamonds, Clubs ]

If we add new enum value to this enum - Swift will protect us and force us 
to add one more case: in each "switch self".
But! It will not protect us from not adding this new value to this "all" 
array. This is absolutely not-Swift way.


Without such "all" property, how will you iterate values for such enum? I 
didn't find any good method to iterate enums.


In Delphi(yes, I know ;-) you can iterate enums using such syntax:
i: EnumType
for i := Low(EnumType) to High(EnumType)
i.e. it will always work correctly, don't need to change this if you added 
value.

and can have such declaration of array where indexes are EnumType:
a: array [EnumType] of String = ('1', '2', '3', '4')
and it will force you to fill/fix this array if you added/deleted the enum 
value.


In Swift we need something to normally iterate enum values. Probably some 
.next()->EnumType? method for each value or built-in .all:[EnumType] property.


Am I wrong somewhere? Are there some plans to improve enums?

On 08.04.2016 21:13, Kenny Leung via swift-evolution wrote:

I much prefer the Java style of enums, which are essentially classes limited to 
a fixed set of instances. In Java, Suit would look like this:

public enum Suit {
Hearts("♥", true),
Spades("♠", false),
Diamonds("♦", true),
Clubs("♣", false);

String description;
boolean isRed;

Suit(String description, boolean isRed) {
   this.description = description;
   this.isRed = isRed;
}
}

The class java.lang.Enum already provides handy methods like
 name(),
 ordinal(),
 toString(), and its inverse, valueOf()
 values() - to get all values

-Kenny


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

Re: [swift-evolution] Limit checking syntax

[Vladimir.S via swift-evolution]

100% Agree. IMO .isIn is perfect :-)
I think the main idea is to allow us to check bounds of some value(usually 
integer) in nice and readable manner.


On 08.04.2016 21:21, Dave Abrahams via swift-evolution wrote:

API guidelines prescribe this should read as an assertion about x, so:

  x.isContainedIn(0..<100)

or

  x.isIn(0..<100)

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead
simple, because if we need to declare precedence group in body of infix
operators, then other operators should have it for consistency.

It's not.
I suggest an alternative syntax for that:
infix operator <> : Comparative

Colon immediately after the operator may not look the best, but it's the
only disadvantage I can find. It looks like inheritance and has similar
meaning.
So, in this scheme, all operators will have no body.

I also described two methods to declare that operator belongs to a
precedence group: in `members` and in operator declaration.
I suggest that this new syntax looks brief/natural enough to remove
`members` option entirely. "There should be one - and preferably only one -
obvious way to do it."

- Anton

2016-04-08 19:59 GMT+03:00 Антон Жилин :

> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was
> what I needed to do it.
> So, the proposal is now completely overhauled:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Yes, Maximilian and I have considered operator/precedence groups and they
> have now moved from alternatives to main part of the proposal.
>
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that
> every operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity:
> left` or `associativity(left)`? So far, only second form has been used
> somewhere inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>
> Just in case, some questions/concerns copied from previous discussion:
>
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than
> Comparative or Ternary, or, at least, Assignment.
>
> 2. Moreover, I could not find any case where I had to write anything other
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should
> have less priority than their custom operator.
>
> But... can you build a custom operator where `<` will actually be needed?
> I have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or
> something without losing any expressivity?
>
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of such operator?
>
> - Anton
>
> 2016-04-08 8:59 GMT+03:00 Chris Lattner :
>
>>
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> First of all, sorry for the delay. I still hope to finish the discussion
>> and push the proposal to review for Swift 3.0.
>> Link for newcomers:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in
>> the beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence
>> groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I
>> still have not heard anything from Core team.
>>
>>
>> Hi Антон,
>>
>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>> 2c:
>>
>> - I completely agree that numeric precedences are lame, it was always the
>> “plan” that they’d be removed someday, but that obviously still hasn’t
>> happened :-)
>> - I definitely agree that a partial ordering between precedences is all
>> that we need/want, and that unspecified relations should be an error.
>>
>> That said, I feel like #operator is a major syntactic regression, both in
>> consistency and predictability.  We use # for two things: directives (like
>> #if) and for expressions (#file).  The #operator is a declaration of an
>> operator, not an expression or a directive.  For declarations, we
>> consistently use a keyword, which allows contextual modifiers before them,
>> along with a body (which is sometimes optional for certain kinds of
>> decls).  I feel like you’re trying to syntactically reduce the weight of
>> something that doesn’t occur very often, which is no real win in
>> expressiveness, and harms consistency.
>>
>> Likewise #precedence is a relationship between two operators.  I’d
>> suggest putting them into the body of the operator declaration.
>>
>> OTOH, the stuff inside the current operator declaration is a random
>> series of tokens with no apparent structure.  I think it would be
>> reasonable to end up with something like:
>>
>> infix operator <> {
>>   associativity: left
>>   precedenceLessThan: *
>>   precedenceEqualTo: -
>>  }
>>
>> Or whatever.  The rationale he

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[David Waite via swift-evolution]

> On Apr 8, 2016, at 4:19 AM, Haravikk via swift-evolution 
>  wrote:

>  If we want mutating forms of this methods then I much prefer .map() and 
> .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts 
> the naming convention used everywhere else which only adds confusion.


Strong -1 to recycling the meaning of 'map' or any of the others to be the 
mutating versions. That would make 'map' fundamentally different and even 
counter to the term of art

-DW

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

[swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Erica Sadun via swift-evolution]

Draft here: https://gist.github.com/erica/a51a981ee0352235204692affa959307 
  Feedback 
solicited, both positive and negative. 
We've also got a related proposal about expanding ranges, which you can look at 
here (https://gist.github.com/erica/af92c541a0fb69fce1b7aaf8374a5aa9 
)
 but we want to float this one first.

Thanks, -- E



Proposal: SE- 

Author(s): Xiaodi Wu , Pyry Jahkola 
, Nate Cook , Erica 
Sadun 
Status: TBD
Review manager: TBD
 
Introduction

We propose to introduce a striding(by:) method on the revised 3.0 Range type.

This proposal was discussed on the Swift Evolution list in the Feature 
proposal: Range operator with step 

 thread. (Direct link 
 to 
original thread)

 
Motivation

Updating Range for Swift 3 offers a window of opportunity to simultaneously 
improve strides.

Under current Swift 3 plans, n.stride(to:/through:, by:) will be replaced with 
a standalone stride(from:, to:/through:, by:) function. We propose to replace 
this change with a method on ranges. Using a method reduces overall API surface 
area compared to free functions.

In its current incarnation, the standalone stride function uses confusing 
semantics. The current to implementation returns values in [start, end) and 
will never reach or get to end. The current through implementation returns 
values in [start, end]. It may never reach end and certainly never goes through 
that value. Our proposed method introduces simple, expected semantics that can 
be extended to both countable and continuous ranges, and to open and closed 
intervals (both half-open and fully-open).

 
Detail
 Design

The striding(by:) method is called on ranges. When used with a positive step 
size, the count starts from the lower bound. With a negative step size, the 
count starts from the upper bound. These bounds apply regardless of whether 
they are inclusive or exclusive. 

The following examples should cover all corner cases and include possible cases 
should Swift 3 introduce a full complement of open and closed ranges. The 
syntax for non-canonical range types is not fixed and can be discussed under 
separate cover.

(0 ... 9).striding(by: 2) == [0, 2, 4, 6, 8]
(0 ..< 9).striding(by: 2) == [0, 2, 4, 6, 8]
(0 <.. 9).striding(by: 2) ==[2, 4, 6, 8]
(0 <.< 9).striding(by: 2) ==[2, 4, 6, 8]

(0 ... 9).striding(by: 3) == [0, 3, 6, 9]
(0 ..< 9).striding(by: 3) == [0, 3, 6]
(0 <.. 9).striding(by: 3) ==[3, 6, 9]
(0 <.< 9).striding(by: 3) ==[3, 6]

(0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1]
(0 ..< 9).striding(by: -2) ==[7, 5, 3, 1]
(0 <.. 9).striding(by: -2) == [9, 7, 5, 3, 1]
(0 <.< 9).striding(by: -2) ==[7, 5, 3, 1]

(0 ... 9).striding(by: -3) == [9, 6, 3, 0]
(0 ..< 9).striding(by: -3) ==[6, 3, 0]
(0 <.. 9).striding(by: -3) == [9, 6, 3]
(0 <.< 9).striding(by: -3) ==[6, 3]
To reverse a stride, call reverse() on the results:

(0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
We note that striding by 0 should be always be a precondition failure.

 
Alternatives
 Considered

During the on-list discussion, we considered various scenarios that took 
closed/inclusive bounds into account or excluded open bounds for starting 
values. For example, we might have prohibited scenarios where multiple 
interpretations of an intended behavior might exist: is (0 ..< 9).striding(by: 
-2) a precondition failure? We settled on the simplest, most straight-forward 
implementation involving the fewest compiler warnings and the lowest likelihood 
of precondition failures. We subscribe to the "Dave Abrahams Philosophy": 
excessive special casing and warning scenarios more likely indicates bad 
language design than bad user comprehension.

 
Future
 Directions

We intend to follow up with an expanded operator vocabulary that includes fully 
open ranges (<.<), fully closed ranges (...) and both half open ranges (<.., 
..<). These will support the full vocabulary laid out in the Detail Design 
section.

Upon adoption, the Swift community may consider expanding this approach to 
collection indices, for example:

let a = [8, 6, 7, 5, 3, 0, 

Re: [swift-evolution] Shortcut for creating arrays

[Dave Abrahams via swift-evolution]

on Fri Apr 08 2016, Arsen Gasparyan  wrote:

> I want to find a conciseness and simplicity solution. But
> componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet()) 
> scares
> me :)

Yes, we should have words.split() at some point.  IMO this is in scope
for a redesign of strings that is expected, but not on the immediate
horizon.

>
>
> On Fri, Apr 8, 2016 at 7:39 PM James Campbell
>  wrote:
>
> Exactly 
>
> Sent from Supmenow.com
>
> On Fri, Apr 8, 2016 at 9:38 AM -0700, "Ross O'Brien"
>  wrote:
>
> A function that splits by whitespace would be this:
>
> "h j c k".componentsSeparatedByCharactersInSet
> (NSCharacterSet.whiteCharacterSet())
>
> 'componentsSeparatedByWhitespace' might be a nice addition as a 
> shortcut
> for that though?
>
> On Fri, Apr 8, 2016 at 3:38 PM, James Campbell 
> wrote:
>
> Pehaps we could have a function that splits by whitespace.
>
> "h j c k".split()
>
> ___
>
> James⎥Alex's Minder
>
> ja...@supmenow.com⎥supmenow.com
>
> Sup
>
> Runway East

>
> 10 Finsbury Square
>
> London
>
> 
EC2A 1AF 
>
> On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution
>  wrote:
>
> Well, you can do this already:
> let words = "rats live on no evil
> star".componentsSeparatedByString(" ")
> so I don't know how much a shortcut is needed.
>
> And given '%w' would currently be impossible in Swift as an
> operator containing a letter, is there a Swiftier function 
> name
> or operator for this?
>
> On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via
> swift-evolution
>  wrote:
>
> Hey guys,
>
> Very often we need to create an array strings. It's a
> routine task and I really like shortcut in Ruby that
> shortcut makes everyday coding a little bit easier and 
> fun:
>
> words = %w[rats live on no evil star]
>
> What do you think about adding something like this in 
> Swift?
>
> Cheers,
> Arsen
>
> ___
> 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

-- 
Dave

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Fri Apr 08 2016, Erica Sadun  wrote:

>> On Apr 6, 2016, at 3:32 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed Apr 06 2016, Erica Sadun  wrote:
>> 
>
>>>On Apr 6, 2016, at 3:25 PM, Dave Abrahams  wrote:
>>> 
>>>These all look reasonable to me.
>>> 
>>>Lastly, if you want the positive stride reversed, you'd do just that:
>>> 
>>>(0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
>>> 
>>>Also reasonable.
>>> 
>>>-- 
>>>Dave
>>> 
>>> Unless there's a compelling reason to fight here, it looks like the
>>> opinion against where I'm standing is pretty overwhelming at least in
>>> this subgroup. To simplify things going forward (and to avoid compiler
>>> warnings, which as Dave A points out is probably an indication of bad
>>> design more than bad users), I'm willing to adopt in as well.
>> 
>> Thanks.  In that case, I suggest that we entertain two separate
>> proposals:
>> 
>> 1. add the .striding(by: n) method.
>> 2. add the other range operators.
>> 
>> Though they both have obvious benefits, I expect #1 is a much easier
>> sell than #2, which is one good reason to separate them.
>> 
>> -- 
>> Dave
>
> I may have misunderstood the intent so I want to clarify: Dave, you'd like to 
> push on these
> now (starting with #1) and not wait for the rest of the Range stuff to
> come online, right?

I'd like to make progress on #1. I think we should hold
the review until the new range stuff is reviewed (happening in the next
few days).  I'm still slightly undecided about #2, but I think it
deserves its own distinct discussion in this list.  #2 might imply some
changes to the protocols we're introducing in the swift-3-indexing-model
branch/proposal, so it needs a little time to percolate here I think.

needing-to-get-back-to-proposal-writing-now'ly yr's,

-- 
Dave

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

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[Dave Abrahams via swift-evolution]

on Fri Apr 08 2016, Pyry Jahkola  wrote:

> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution
>  wrote:
>
> I think it makes sense to just rename them; it’s not as though flattened 
> or
> mapped is somehow far removed from the original meaning as the actual 
> action
> is the same, it’s just changing tense.
>
> -1, and not only for the reasons we neither call trigonometric functions 
> `sine`,
> `cosine`, and `tangent`. The existing names are widely known, commonly taught 
> in
> modern introductory programming courses, to the point, and googleable.
>
> In addition:
>
> If we want mutating forms of this methods then I much prefer .map() and .
> mapped() to .map() and .mapInPlace() or whatever, as the latter 
> contradicts
> the naming convention used everywhere else which only adds confusion.
>
> This idea of in-place versions is innocuous but absurd. In general, there's no
> way mapping `T -> U` over a `[T]` could possibly accommodate the result in the
> argument of type `[T]`:
>
> var xs: [Int] = ...
> xs.mapInPlace {String($0)} // ???

No, you'd just give it a more-restricted signature that only accepted
T->T closures.

> And the same goes for `flatMap`, and `Optional` and others. Likewise, 
> `flatten()
> ` couldn't possibly happen in place because the result type has one level of
> nesting less than the argument.

C'rect.
-- 
Dave

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

Re: [swift-evolution] Limit checking syntax

[Dave Abrahams via swift-evolution]

on Fri Apr 08 2016, "Vladimir.S via swift-evolution" 
 wrote:

> On 08.04.2016 4:14, Harlan Haskins via swift-evolution wrote:
>> I’ve found that .contains works well for all my uses.
>>
>> (0..<100).contains(x)
>
> Hmm.. Isn't next construction is much more readable?:
>
> x.in(0..<100)

API guidelines prescribe this should read as an assertion about x, so:

 x.isContainedIn(0..<100)

or 

 x.isIn(0..<100)

FWIW.

> I think it is much more readable.
> We are planning(in head) to verify "if x value is in range from 0 up
> to 99", so why we have to write "for some range 0 to 9 let's check if
> it contains our x value".
> Our x is a subject of our check, not range (0..<100).
>
> I.e. in my opinion -1 for 'in' operator like suggested in initial message,
> but +1 for .in method for integer to check against range
> Any additional opinion?
>
> Vladimir
> (P.S. Sorry for duplicate.)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Dave Abrahams via swift-evolution]

on Thu Apr 07 2016, Taras Zakharko  wrote:

> replaceWith* is also my favourite here (same for *InPlace). 

The latter is great because it's a suffix, but it is not as grammatical
as the former.  Aside from syntactic weight, I'd say these are about
equal.

> Sure, it might be verbose, but the semantics is very clear and seems
> apply to a wide range of relevant situations. In the end, there are
> hundreds if not more messages in this (and related) threads and i am
> sure that you guys spent even more time in meetings talking about
> this. If I understand correctly, Swifts goal is clarity over
> laconicity. If finding sensible laconic terminology turns out to be
> surprisingly difficult, a more verbose one might be a better choice
> after all.

I don't think “formXXX” is “not sensible,” even though it may have
disadvantages.  If “replaceWithXXX” is an improvement, IMO, it's a
marginal one.  “formXXX” actually has one important advantage over
“replaceWithXXX:” the former suggests the true performance nature of the
operation, which is *the* reason you'd choose it over the non-in-place
version, whereas the latter strongly suggests an implementation like
`self = XXX()`.

>
>
> — Taras
>
>> On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Mon Apr 04 2016, Brent Royal-Gordon  wrote:
>> 
 Indeed, OED points out that modern usage is "chiefly military." Probably 
 an argument against its usage here.
>>> 
>>> It seems to me that what you're sort of saying is "replaceWith", but
>>> that's kind of a mouthful. 
>> 
>> It's at least very explicit.  We did consider that, and chose “form” as
>> a more reasonable convention.  However, we weren't thinking of the
>> “from” problem.  I prefer “replaceWith” over “become” for some reason I
>> can't identify.
>> 
>>> A quick thesaurus check suggests that the only decent single-world
>>> alternative would be "substitute", but that sounds like a regex
>>> operation. I think this is a dead end.
>> 
>> -- 
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Kenny Leung via swift-evolution]

I much prefer the Java style of enums, which are essentially classes limited to 
a fixed set of instances. In Java, Suit would look like this:

public enum Suit {
   Hearts("♥", true),
   Spades("♠", false),
   Diamonds("♦", true),
   Clubs("♣", false);

   String description;
   boolean isRed;

   Suit(String description, boolean isRed) {
  this.description = description;
  this.isRed = isRed;
   }
}

The class java.lang.Enum already provides handy methods like
name(),
ordinal(), 
toString(), and its inverse, valueOf()
values() - to get all values

-Kenny

> On Mar 23, 2016, at 3:13 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> If you've written enums before, you've no doubt noticed the irritating 
> phenomenon of `switch self` being absolutely everywhere. I first discovered 
> this in some of my very first Swift code, code so old we were still using the 
> `T[]` shorthand syntax:
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>var description: String {
>switch(self) {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
>}
> 
>var isRed: Bool {
>switch(self) {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
>}
> 
> It would be nice if we could somehow eliminate that. I have two suggestions:
> 
> * Implicitly switch on `self` at the top level of a function or accessor (or 
> at least an enum one with top-level `case` statements).
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
> 
>var description: String {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
> 
>var isRed: Bool {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
> 
> * Allow you to attach member definitions to particular cases. It would be an 
> error if they didn't all define the same members, unless there was a 
> top-level catchall.
> 
>enum Suit: Int {
>var isRed: Bool { return false }
> 
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}
> 
> Any thoughts? This has, to be honest, bothered me since approximately the 
> third day I used the language; I'd love to address it sooner or later.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 3:32 PM, Dave Abrahams  wrote:
> 
> 
> on Wed Apr 06 2016, Erica Sadun  wrote:
> 
>>On Apr 6, 2016, at 3:25 PM, Dave Abrahams  wrote:
>> 
>>These all look reasonable to me.
>> 
>>Lastly, if you want the positive stride reversed, you'd do just that:
>> 
>>(0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
>> 
>>Also reasonable.
>> 
>>-- 
>>Dave
>> 
>> Unless there's a compelling reason to fight here, it looks like the
>> opinion against where I'm standing is pretty overwhelming at least in
>> this subgroup. To simplify things going forward (and to avoid compiler
>> warnings, which as Dave A points out is probably an indication of bad
>> design more than bad users), I'm willing to adopt in as well.
> 
> Thanks.  In that case, I suggest that we entertain two separate
> proposals:
> 
> 1. add the .striding(by: n) method.
> 2. add the other range operators.
> 
> Though they both have obvious benefits, I expect #1 is a much easier
> sell than #2, which is one good reason to separate them.
> 
> -- 
> Dave

I may have misunderstood the intent so I want to clarify: Dave, you'd like to 
push on these
now (starting with #1) and not wait for the rest of the Range stuff to come 
online, right?

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Dave Abrahams via swift-evolution]

on Thu Apr 07 2016, Xiaodi Wu  wrote:

> If we're going to bikeshed again: how about "assign"?

It begs for a preposition, which is usually “to,” which has the wrong
meaning :(

> On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution
>  wrote:
>
> replaceWith* is also my favourite here (same for *InPlace). Sure, it might
> be verbose, but the semantics is very clear and seems apply to a wide 
> range
> of relevant situations. In the end, there are hundreds if not more 
> messages
> in this (and related) threads and i am sure that you guys spent even more
> time in meetings talking about this. If I understand correctly, Swifts 
> goal
> is clarity over laconicity. If finding sensible laconic terminology turns
> out to be surprisingly difficult, a more verbose one might be a better
> choice after all.
>
> — Taras
>
> > On 07 Apr 2016, at 22:36, Dave Abrahams via swift-evolution
>  wrote:
> >
> >
> > on Mon Apr 04 2016, Brent Royal-Gordon  
> wrote:
> >
> >>> Indeed, OED points out that modern usage is "chiefly military." 
> Probably
> an argument against its usage here.
> >>
> >> It seems to me that what you're sort of saying is "replaceWith", but
> >> that's kind of a mouthful.
> >
> > It's at least very explicit. We did consider that, and chose “form” as
> > a more reasonable convention. However, we weren't thinking of the
> > “from” problem. I prefer “replaceWith” over “become” for some reason I
> > can't identify.
> >
> >> A quick thesaurus check suggests that the only decent single-world
> >> alternative would be "substitute", but that sounds like a regex
> >> operation. I think this is a dead end.
> >
> > --
> > Dave
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

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

Re: [swift-evolution] Shortcut for creating arrays

[Tino Heth via swift-evolution]

I would create a computed property on String and call it "words"

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Right, `infix` operators without a precedence group logically should be
able to be used, just with parentheses everywhere.

But users will most likely want to use such operators with `=` without
parentheses. It means, such operators should still belong to some
precedence groups.

I suggest that for each such operator, an separate unnamed group should be
created. It will have no associativity and precedence greater than Ternary
(I actually agree this is the right choice).

I also think it is OK that other operators will not be able to specify
precedence relation with such "unprecedented" operators.

- Anton

8 Apr 2016, Ross O'Brien wrote:

> If I want to define a new operator, it seems like an unnecessary overhead
> to have to immediately decide which precedence group it should belong to
> before it can be used (assuming it doesn't interact with other operators).
> At the moment, new operators are implicitly assigned a 'default' precedence
> of 100; can we make it so that new operators are implicitly assigned to a
> 'default' group with an effective precedence of 100? (I believe this is
> currently the precedence of Ternary, but I'm not sure if I'd have Ternary
> be the default group).
>
> On Fri, Apr 8, 2016 at 5:59 PM, Антон Жилин  > wrote:
>
>> Thank you for your reply, Chris!
>> I was thinking about purging directives from the proposal, and that was
>> what I needed to do it.
>> So, the proposal is now completely overhauled:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Yes, Maximilian and I have considered operator/precedence groups and they
>> have now moved from alternatives to main part of the proposal.
>>
>> Questions:
>> 1. Is it OK that associativity is moved to precedence groups and that
>> every operator must belong to a precedence group?
>> 2. Dictionary-like or "functional keywords"? That is, `associativity:
>> left` or `associativity(left)`? So far, only second form has been used
>> somewhere inside declarations.
>> 3. First-lower or first-upper? `additive` or `Additive`?
>> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>>
>> Just in case, some questions/concerns copied from previous discussion:
>>
>> 1. All precedence groups have a "parent".
>> It means, all operators will want to have precedence higher than
>> Comparative or Ternary, or, at least, Assignment.
>>
>> 2. Moreover, I could not find any case where I had to write anything
>> other than precedence(>, ...)
>> Of cause, I cheated, because I can control all these declarations.
>> Mere people will have to use `<` to say that Additive, for example,
>> should have less priority than their custom operator.
>>
>> But... can you build a custom operator where `<` will actually be needed?
>> I have even stronger doubts on `=`.
>> Maybe we can even contract this feature to `parent(Comparative)` or
>> something without losing any expressivity?
>>
>> 3. Can we allow operators to have less priority than `=`?
>> If yes, can you give an example of such operator?
>>
>> - Anton
>>
>> 2016-04-08 8:59 GMT+03:00 Chris Lattner > >:
>>
>>>
>>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>>> swift-evolution@swift.org
>>> > wrote:
>>>
>>> First of all, sorry for the delay. I still hope to finish the discussion
>>> and push the proposal to review for Swift 3.0.
>>> Link for newcomers:
>>>
>>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>>
>>> Sadly, I've moved into the territory opposite to what I had in mind in
>>> the beginning: absense of conflict resolution.
>>> I wanted lightweight directives, but am moving to closed precedence
>>> groups.
>>>
>>> It's just IMHO, and I think I just need input on this from more people.
>>> I still have not heard anything from Core team.
>>>
>>>
>>> Hi Антон,
>>>
>>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>>> 2c:
>>>
>>> - I completely agree that numeric precedences are lame, it was always
>>> the “plan” that they’d be removed someday, but that obviously still hasn’t
>>> happened :-)
>>> - I definitely agree that a partial ordering between precedences is all
>>> that we need/want, and that unspecified relations should be an error.
>>>
>>> That said, I feel like #operator is a major syntactic regression, both
>>> in consistency and predictability.  We use # for two things: directives
>>> (like #if) and for expressions (#file).  The #operator is a declaration of
>>> an operator, not an expression or a directive.  For declarations, we
>>> consistently use a keyword, which allows contextual modifiers before them,
>>> along with a body (which is sometimes optional for certain kinds of
>>> decls).  I feel like you’re trying to syntactically reduce the weight of
>>> something that doesn’t occur very often, which is no real win in
>>> expressi

[swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

[Erica Sadun via swift-evolution]

Is there a best way to request default values for common Cocoa and Cocoa Touch 
APIs? 
Now that we're moving to Swift, the language supports defaults and omitted 
parameters
but the ObjC APIs do not (yet) supply them. 

For example, dismissViewControllerAnimated(flag: true, completion: nil) 
could become dismissAnimated() when default values are available for flag and 
completion.
There's a large-ish class of these boilerplate defaults and it would be nice if 
there were a way to
be able to request them.

cc'ing in Daniel S whose idea this is.

Thanks, -- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

[Matt Whiteside via swift-evolution]

> On Apr 6, 2016, at 17:13, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Another nice thing about this style is that, in principle, I think it could 
> be extended to specify requirements on non-type parameter values.

I had this thought too.  The possibilities that this syntax change suggests for 
compile time evaluation are very interesting, in my opinion.

-Matt

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

Re: [swift-evolution] [Proposal] Custom operators

[Ross O'Brien via swift-evolution]

If I want to define a new operator, it seems like an unnecessary overhead
to have to immediately decide which precedence group it should belong to
before it can be used (assuming it doesn't interact with other operators).
At the moment, new operators are implicitly assigned a 'default' precedence
of 100; can we make it so that new operators are implicitly assigned to a
'default' group with an effective precedence of 100? (I believe this is
currently the precedence of Ternary, but I'm not sure if I'd have Ternary
be the default group).

On Fri, Apr 8, 2016 at 5:59 PM, Антон Жилин 
wrote:

> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was
> what I needed to do it.
> So, the proposal is now completely overhauled:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Yes, Maximilian and I have considered operator/precedence groups and they
> have now moved from alternatives to main part of the proposal.
>
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that
> every operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity:
> left` or `associativity(left)`? So far, only second form has been used
> somewhere inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>
> Just in case, some questions/concerns copied from previous discussion:
>
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than
> Comparative or Ternary, or, at least, Assignment.
>
> 2. Moreover, I could not find any case where I had to write anything other
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should
> have less priority than their custom operator.
>
> But... can you build a custom operator where `<` will actually be needed?
> I have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or
> something without losing any expressivity?
>
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of such operator?
>
> - Anton
>
> 2016-04-08 8:59 GMT+03:00 Chris Lattner :
>
>>
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> First of all, sorry for the delay. I still hope to finish the discussion
>> and push the proposal to review for Swift 3.0.
>> Link for newcomers:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in
>> the beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence
>> groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I
>> still have not heard anything from Core team.
>>
>>
>> Hi Антон,
>>
>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>> 2c:
>>
>> - I completely agree that numeric precedences are lame, it was always the
>> “plan” that they’d be removed someday, but that obviously still hasn’t
>> happened :-)
>> - I definitely agree that a partial ordering between precedences is all
>> that we need/want, and that unspecified relations should be an error.
>>
>> That said, I feel like #operator is a major syntactic regression, both in
>> consistency and predictability.  We use # for two things: directives (like
>> #if) and for expressions (#file).  The #operator is a declaration of an
>> operator, not an expression or a directive.  For declarations, we
>> consistently use a keyword, which allows contextual modifiers before them,
>> along with a body (which is sometimes optional for certain kinds of
>> decls).  I feel like you’re trying to syntactically reduce the weight of
>> something that doesn’t occur very often, which is no real win in
>> expressiveness, and harms consistency.
>>
>> Likewise #precedence is a relationship between two operators.  I’d
>> suggest putting them into the body of the operator declaration.
>>
>> OTOH, the stuff inside the current operator declaration is a random
>> series of tokens with no apparent structure.  I think it would be
>> reasonable to end up with something like:
>>
>> infix operator <> {
>>   associativity: left
>>   precedenceLessThan: *
>>   precedenceEqualTo: -
>>  }
>>
>> Or whatever.  The rationale here is that “infix” is primal on the
>> operator decl (and thus is outside the braces) but the rest of the stuff
>> can be omitted, so it goes inside.
>>
>> Just in terms of the writing of the proposal, in the "Change precedence
>> mechanism” keep in mind t

Re: [swift-evolution] Shortcut for creating arrays

[Vladimir.S via swift-evolution]

As I understand in initial message, string should be splitted by spaces, 
not all kind of whitespaces(like TAB). whiteCharacterSet() is not just 
space(at least TAB char there too).
So, if we need split just by space we need some 
componentsSeparatedBySpaceCharacter(). And IMO this is not a good solution.


Actually "a b c".componentsSeparatedByString(" ") works well, but probaly 
it will be good to have something like
"a:b-->c/d".componentsSeparatedByStrings(":", "-->", "/"). But I'm not sure 
about this :-)


On 08.04.2016 19:38, Ross O'Brien via swift-evolution wrote:

A function that splits by whitespace would be this:

"h j c
k".componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet())

'componentsSeparatedByWhitespace' might be a nice addition as a shortcut
for that though?

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Thank you for your reply, Chris!
I was thinking about purging directives from the proposal, and that was
what I needed to do it.
So, the proposal is now completely overhauled:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Yes, Maximilian and I have considered operator/precedence groups and they
have now moved from alternatives to main part of the proposal.

Questions:
1. Is it OK that associativity is moved to precedence groups and that every
operator must belong to a precedence group?
2. Dictionary-like or "functional keywords"? That is, `associativity: left`
or `associativity(left)`? So far, only second form has been used somewhere
inside declarations.
3. First-lower or first-upper? `additive` or `Additive`?
4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?

Just in case, some questions/concerns copied from previous discussion:

1. All precedence groups have a "parent".
It means, all operators will want to have precedence higher than
Comparative or Ternary, or, at least, Assignment.

2. Moreover, I could not find any case where I had to write anything other
than precedence(>, ...)
Of cause, I cheated, because I can control all these declarations.
Mere people will have to use `<` to say that Additive, for example, should
have less priority than their custom operator.

But... can you build a custom operator where `<` will actually be needed? I
have even stronger doubts on `=`.
Maybe we can even contract this feature to `parent(Comparative)` or
something without losing any expressivity?

3. Can we allow operators to have less priority than `=`?
If yes, can you give an example of such operator?

- Anton

2016-04-08 8:59 GMT+03:00 Chris Lattner :

>
> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> First of all, sorry for the delay. I still hope to finish the discussion
> and push the proposal to review for Swift 3.0.
> Link for newcomers:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Sadly, I've moved into the territory opposite to what I had in mind in the
> beginning: absense of conflict resolution.
> I wanted lightweight directives, but am moving to closed precedence groups.
>
> It's just IMHO, and I think I just need input on this from more people. I
> still have not heard anything from Core team.
>
>
> Hi Антон,
>
> I’m sorry for the delay, I have been out of town recently.  I haven’t read
> the upstream thread so I hope this isn’t too duplicative.  Here is my 2c:
>
> - I completely agree that numeric precedences are lame, it was always the
> “plan” that they’d be removed someday, but that obviously still hasn’t
> happened :-)
> - I definitely agree that a partial ordering between precedences is all
> that we need/want, and that unspecified relations should be an error.
>
> That said, I feel like #operator is a major syntactic regression, both in
> consistency and predictability.  We use # for two things: directives (like
> #if) and for expressions (#file).  The #operator is a declaration of an
> operator, not an expression or a directive.  For declarations, we
> consistently use a keyword, which allows contextual modifiers before them,
> along with a body (which is sometimes optional for certain kinds of
> decls).  I feel like you’re trying to syntactically reduce the weight of
> something that doesn’t occur very often, which is no real win in
> expressiveness, and harms consistency.
>
> Likewise #precedence is a relationship between two operators.  I’d suggest
> putting them into the body of the operator declaration.
>
> OTOH, the stuff inside the current operator declaration is a random series
> of tokens with no apparent structure.  I think it would be reasonable to
> end up with something like:
>
> infix operator <> {
>   associativity: left
>   precedenceLessThan: *
>   precedenceEqualTo: -
>  }
>
> Or whatever.  The rationale here is that “infix” is primal on the operator
> decl (and thus is outside the braces) but the rest of the stuff can be
> omitted, so it goes inside.
>
> Just in terms of the writing of the proposal, in the "Change precedence
> mechanism” keep in mind that swift code generally doesn’t care about the
> order of declarations (it doesn’t parse top down in the file like C does)
> so the example is a bit misleading.
>
> Question for you: have you considered introducing named precedence groups,
> and having the relationships be between those groups?  For example, I could
> see something like:
>
> operator group additive {}
> operator group multiplicative { greaterThan: additive }
> operator group exponential { greaterThan: additive }
>
> Then:
>
> infix operator + {
>   associativity: left
>   precedence: additive
>  }
> infix operator - {
>   associativity: left
>   precedence: additive
>  }
>
> etc.
>
> -Chris
>
___
swift-evolution ma

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Jonathan Hull via swift-evolution]

My main point was that, this was an extremely common practice in Objective C 
(one which was even used/encouraged by Apple for quite a while) and the 
proposal needs to address it.  There is a lot of working code out there that 
uses this pattern.  In short, we need to be careful not to accidentally trip 
all of those magical behavior changes you were talking about, since it would 
effectively break that code.

It is one thing to say that there is a better way to approach this problem for 
new code in Swift… it is another entirely to say that code written this way 
years ago in ObjC (and which works today with Swift) can’t be used with Swift 
3.0 without a major refactoring effort.

Thanks,
Jon

P.S.  I will leave my secondary point (that I would like to see more of 
Smalltalk’s abilities in Swift) alone for the most part, since it seems to be 
distracting from my main point that the proposal would break code which 
currently works.

> Table view semantics were discussed at length on a prior version of the
> thread. That pattern is less than ideal; it essentially creates magic
> behavior that's only described by documentation… or, worse, completely
> forgotten about in documentation; something changing from version to
> version of the framework; etc. I can not tell you how many times this
> has tripped up members of my teams. Over in Cocoa proper, similar
> behavior changes also arise (usually performance optimizations) from
> whether or not you *override* a method, and it's even more confusing.
>  
> Such a practice should not be a cornerstone of a modern language; as
> discussed in the prior thread, the different semantics of the measuring
> methods (the current return values, as well as the implicit one from not
> overriding) should be captured explicitly in an enum, with a clear
> default return value. This is in line with the spirit of Swift. Your API
> contract with the user is clear, and the introduction of default
> implementations is versioned as a matter of public API.
>  
> It's interesting that you use the phrase "customization points". Our
> text for teaching protocol extensions in Swift uses it heavily - that
> *is* the behavior of protocols with default implementations in Swift
> today. You delegate something out, but give it a default implementation
> with logic you specify. That's a customization point, too.
>  
> Cheers!
> Zachary Waldowski
> zach at waldowski.me 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Dmitri Gribenko via swift-evolution]

On Fri, Apr 8, 2016 at 3:49 AM, Vladimir.S  wrote:
>
>
> On 07.04.2016 21:43, Dmitri Gribenko wrote:
>>
>> There would be no need to.  Collection will have a .successor(of:)
>> method that returns the next index after the given one.
>>
>
> I see. Thank you for letting know about this.
>
>> I can see that, but when you know that you are dealing with an
>> integer, isn't "+ 1" a more common and readable notation?
>
>
> Hmm.. I believe that i++ is muuuch common used than i += 1 ;-)

The reason why I said "+ 1" is because this discussion is about
Int.successor(), which returns a new Int rather than mutating it in
place.  So i++ and i += 1 are not direct replacements for
Int.successor().

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] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[Vladimir.S via swift-evolution]

Yes, IMO it really looks strange.
Just checked:

class Foo {
static var test = "test"

static var bar: String = {
print("static")
return "Default"
}()

lazy var baz: String = {
print("lazy")
return "Lazy"
}()
}


print("1")
print(Foo.test)
print("2")
Foo.bar = "Set"
print("3")
let foo = Foo()
foo.baz = "Set"
print("4")

we have :
1
test
2
static
3
4

I strongly believe as static property is lazy by definition, it must not be 
evaluated at all when we set it. This is something that "lazyness" promises 
to us - that it will be called/calculated ONLY when we ask for this. So in 
my opinion this is bug/issue and should be fixed/changed in Swift 3.0.



On 08.04.2016 10:36, David Rönnqvist via swift-evolution wrote:

I noticed a difference between how static and lazy variables evaluate closures 
and thought that it was a bug:
https://bugs.swift.org/browse/SR-1178
but apparently it’s not.

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

Re: [swift-evolution] Shortcut for creating arrays

[Arsen Gasparyan via swift-evolution]

I want to find a conciseness and simplicity solution. But
componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet()) scares
me :)

On Fri, Apr 8, 2016 at 7:39 PM James Campbell  wrote:

> Exactly
>
> Sent from Supmenow.com 
>
>
>
>
> On Fri, Apr 8, 2016 at 9:38 AM -0700, "Ross O'Brien" <
> narrativium+sw...@gmail.com> wrote:
>
> A function that splits by whitespace would be this:
>>
>> "h j c
>> k".componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet())
>>
>> 'componentsSeparatedByWhitespace' might be a nice addition as a shortcut
>> for that though?
>>
>>
>> On Fri, Apr 8, 2016 at 3:38 PM, James Campbell 
>> wrote:
>>
>>> Pehaps we could have a function that splits by whitespace.
>>>
>>> "h j c k".split()
>>>
>>> *___*
>>>
>>> *James⎥Alex's Minder*
>>>
>>> *ja...@supmenow.com ⎥supmenow.com
>>> *
>>>
>>> *Sup*
>>>
>>> *Runway East *
>>>
>>> *10 Finsbury Square*
>>>
>>> *London*
>>>
>>> * EC2A 1AF *
>>>
>>> On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Well, you can do this already:
 let words = "rats live on no evil star".componentsSeparatedByString(" ")
 so I don't know how much a shortcut is needed.

 And given '%w' would currently be impossible in Swift as an operator
 containing a letter, is there a Swiftier function name or operator for 
 this?

 On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via swift-evolution <
 swift-evolution@swift.org> wrote:

> Hey guys,
>
> Very often we need to create an array strings. It's a routine task and
> I really like shortcut in Ruby that shortcut makes everyday coding a 
> little
> bit easier and fun:
>
>words = %w[rats live on no evil star]
>
> What do you think about adding something like this in Swift?
>
> Cheers,
> Arsen
>
> ___
> 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] Shortcut for creating arrays

[James Campbell via swift-evolution]

Exactly 

Sent from Supmenow.com




On Fri, Apr 8, 2016 at 9:38 AM -0700, "Ross O'Brien" 
 wrote:










A function that splits by whitespace would be this:
"h j c 
k".componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet())
'componentsSeparatedByWhitespace' might be a nice addition as a shortcut for 
that though?

On Fri, Apr 8, 2016 at 3:38 PM, James Campbell  wrote:
Pehaps we could have a function that splits by whitespace.
"h j c k".split()










___

James⎥Alex's Minder

ja...@supmenow.com⎥supmenow.com

Sup

Runway East


10 Finsbury Square

London


EC2A 1AF 

On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution 
 wrote:
Well, you can do this already:let words = "rats live on no evil 
star".componentsSeparatedByString(" ")so I don't know how much a shortcut is 
needed.
And given '%w' would currently be impossible in Swift as an operator containing 
a letter, is there a Swiftier function name or operator for this?
On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via swift-evolution 
 wrote:
Hey guys,
Very often we need to create an array strings. It's a routine task and I really 
like shortcut in Ruby that shortcut makes everyday coding a little bit easier 
and fun:
   words = %w[rats live on no evil star]
What do you think about adding something like this in Swift?
Cheers,Arsen

___

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] Shortcut for creating arrays

[Ross O'Brien via swift-evolution]

A function that splits by whitespace would be this:

"h j c
k".componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet())

'componentsSeparatedByWhitespace' might be a nice addition as a shortcut
for that though?


On Fri, Apr 8, 2016 at 3:38 PM, James Campbell  wrote:

> Pehaps we could have a function that splits by whitespace.
>
> "h j c k".split()
>
> *___*
>
> *James⎥Alex's Minder*
>
> *ja...@supmenow.com ⎥supmenow.com
> *
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
>
> On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well, you can do this already:
>> let words = "rats live on no evil star".componentsSeparatedByString(" ")
>> so I don't know how much a shortcut is needed.
>>
>> And given '%w' would currently be impossible in Swift as an operator
>> containing a letter, is there a Swiftier function name or operator for this?
>>
>> On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hey guys,
>>>
>>> Very often we need to create an array strings. It's a routine task and I
>>> really like shortcut in Ruby that shortcut makes everyday coding a little
>>> bit easier and fun:
>>>
>>>words = %w[rats live on no evil star]
>>>
>>> What do you think about adding something like this in Swift?
>>>
>>> Cheers,
>>> Arsen
>>>
>>> ___
>>> 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] Ability to pack, order and align certain types of Structs (like in C)

[Hitster GTD via swift-evolution]

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

I am uncertain as to what happens after Swift 3 since there don't seem
to be any guidelines for that; hopefully the above would ensure that
it isn't forgotten. :)

On 8 April 2016 at 07:01, Chris Lattner  wrote:
>
>> On Apr 7, 2016, at 12:28 PM, hitstergtd+swiftevo--- via swift-evolution 
>>  wrote:
>>
>> To the community:
>>
>> Neither am I a compiler/language design expert nor have I previously
>> written a proposal to that effect, so I apologise if I have
>> trivialised the matter especially with regard to other parts of Swift
>> or if some of it already exists. I am also aware that what I've
>> proposed herein maybe possible through alternate means. However, the
>> aim of this is to make it a first-class feature in Swift itself. For
>> those unfamiliar with what is being requested, please see [2], [5] and [8].
>>
>> I have also filed this as a language feature request at [7].
>
> Yes, this would be a great thing to have, but it requires significant design 
> and implementation work, so I’m afraid it is out of scope for Swift 3.  In 
> the meantime, a lame workaround is that you can define your struct in C and 
> import it.  Swift will honor the layout of the C type.
>
> -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[David Rönnqvist via swift-evolution]

I noticed a difference between how static and lazy variables evaluate closures 
and thought that it was a bug:
https://bugs.swift.org/browse/SR-1178
but apparently it’s not.

The difference can be illustrated in a small example. The following code will 
evaluate the closure for the static variable, even when *setting* the variable, 
but won’t evaluate the closure for the lazy variable. Thus, it prints “static”, 
but not “lazy”.

class Foo {
static var bar: String = {
print("static")
return "Default"
}()

lazy var baz: String = {
print("lazy")
return "Lazy"
}()
}

Foo.bar = "Set"

let foo = Foo()
foo.baz = “Set"

I would have thought that neither case should evaluate the closure when setting 
the variable, since the result from the closure is never used in that case. I 
don’t feel that strongly about if the closure is evaluated or not. But I would 
like both types (static and lazy) to behave the same. 

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

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Shawn Erickson via swift-evolution]

I want to reiterate that I have objective-c code, others have objc code,
and the cocoa, etc. frameworks have code that depend on optional protocol
for things like (but not limited to) delegates. This is of course obvious
but what seems to get lost in the discussion is that you can't always
replace the non-existence of an implementation of an optional protocol
method with a default implementation.

I have code that probes a delegate when registered and based on the what
subset of the optional protocol methods it handles configures its runtime
state to optimize itself to that reality. For example it may avoid
allocating and maintaining potentially complex state if one or more methods
are not implemented by the delegate (since no one is interested in it). If
we just blindly provide default implementation for optional methods then
this optimization couldn't take place.

I know others - including I believe Apple framework code - do similar
optimizations based on what methods an object implements.

I think we should maintain the optional concept in support of bridging
existing objc code into swift (confined to @objc)... unless a way to bridge
things can be defined that avoids the loss of optimization potential I
outlined above.

Optional protocols don't need to be expanded into Swift itself since I
believe alternate methods and patterns exists to solve the same type of
need.

-Shawn

On Thu, Apr 7, 2016 at 5:12 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> Optional protocol requirements in Swift have the restriction that they
> only work in @objc protocols, a topic that’s come up a number
>  of
> times
> .
> The start of these threads imply that optional requirements should be
> available for all protocols in Swift. While this direction is
> implementable, each time this is discussed there is significant feedback
> that optional requirements are not a feature we want in Swift. They overlap
> almost completely with default implementations of protocol requirements,
> which is a more general feature, and people seem to feel that designs based
> around default implementations and refactoring of protocol hierarchies are
> overall better.
>
> The main concern with removing optional requirements from Swift is their
> impact on Cocoa: Objective-C protocols, especially for delegates and data
> sources, make heavy use of optional requirements. Moreover, there are no
> default implementations for any of these optional requirements: each caller
> effectively checks for the presence of the method explicitly, and
> implements its own logic if the method isn’t there.
>
> *A Non-Workable Solution: Import as optional property requirements*
> One suggestion that’s come up to map an optional requirement to a property
> with optional type, were “nil” indicates that the requirement was not
> satisfied. For example,
>
> @protocol NSTableViewDelegate
> @optional
> - (nullable NSView *)tableView:(NSTableView *)tableView
> viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row;
> - (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row;
> @end
>
>
> currently comes in as
>
> @objc protocol NSTableViewDelegate {
>   optional func tableView(_: NSTableView, viewFor: NSTableColumn, row:
> Int) -> NSView?
>   optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
> }
>
> would come in as:
>
> @objc protocol NSTableViewDelegate {
>   var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) ->
> NSView?)? { get }
>   var tableView: ((NSTableView, heightOfRow: Int) -> CGFloat)? { get }
> }
>
>
> with a default implementation of “nil” for each. However, this isn’t
> practical for a number of reasons:
>
> a) We would end up overloading the property name “tableView” a couple
> dozen times, which doesn’t actually work.
>
> b) You can no longer refer to the member with a compound name, e.g.,
> “delegate.tableView(_:viewFor:row:)” no longer works, because the name of
> the property is “tableView”.
>
> c) Implementers of the protocol now need to provide a read-only property
> that returns a closure. So instead of
>
> class MyDelegate : NSTableViewDelegate {
>   func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) ->
> NSView? { … }
> }
>
>
> one would have to write something like
>
> class MyDelegate : NSTableViewDelegate {
>   var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) ->
> NSView?)? = {
> … except you can’t refer to self in here unless you make it lazy ...
>   }
> }
>
>
> d) We’ve seriously considered eliminating argument labels on function
> types, because they’re a complexity in the type system that doesn’t serve
> much of a purpose.
>
> One could perhaps work around (a), (b), and (d) by allowing compound
> (function-like) names like tableView(_:viewFor:row:) for properties, and

Re: [swift-evolution] [Review] SE-0062: Referencing Objective-C key-paths

[plx via swift-evolution]

> What is your evaluation of the proposal?
I like it and think it’s something Swift should definitely have.

A quibble: I think there’d be value in also having:

   #key(ClassName.propertyName)

…which is the same as `#keyPath`, but without support for *paths*.

It’s functionally-redundant with the more-general #keyPath but makes intent 
clearer, and is IMHO both shorter and clearer at any call-site that require 
keys, not key-paths.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes for the same reasons #selector was added.

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

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick read, didn’t follow the lead-up discussion.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> 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] [Idea] How to eliminate 'optional' protocol requirements

[Zach Waldowski via swift-evolution]

Table view semantics were discussed at length on a prior version of the
thread. That pattern is less than ideal; it essentially creates magic
behavior that's only described by documentation… or, worse, completely
forgotten about in documentation; something changing from version to
version of the framework; etc. I can not tell you how many times this
has tripped up members of my teams. Over in Cocoa proper, similar
behavior changes also arise (usually performance optimizations) from
whether or not you *override* a method, and it's even more confusing.
 
Such a practice should not be a cornerstone of a modern language; as
discussed in the prior thread, the different semantics of the measuring
methods (the current return values, as well as the implicit one from not
overriding) should be captured explicitly in an enum, with a clear
default return value. This is in line with the spirit of Swift. Your API
contract with the user is clear, and the introduction of default
implementations is versioned as a matter of public API.
 
It's interesting that you use the phrase "customization points". Our
text for teaching protocol extensions in Swift uses it heavily - that
*is* the behavior of protocols with default implementations in Swift
today. You delegate something out, but give it a default implementation
with logic you specify. That's a customization point, too.
 
Cheers!
Zachary Waldowski
z...@waldowski.me
 
 
On Fri, Apr 8, 2016, at 08:47 AM, Jonathan Hull via swift-evolution wrote:
> Interesting proposal, but I wanted to mention a couple of potential
> issues off the top of my head.  I know when I was using optional
> requirements in Objective C, I would often use the presence/lack of
> the method (not just whether it returned nil) in the logic of my
> program.  I used the presence of a method as a way for the implementor
> of a delegate to naturally communicate whether they wanted a more
> advanced feature.  The absence of the method itself is information
> which can be utilized, not just whether it returns nil, and I believe
> that is part of what people are asking for when they say they want
> optional methods in Swift.
>
>
> Let me try to give a simplified example which I am not sure how you
> would work around in this proposal:
>
> Let’s say there is a datasource protocol which optionally asks for an
> image associated with a particular piece of data (imagine a table or
> collection view type custom control).  If the method is not
> implemented in the data source, then a different view is shown for
> each data point that doesn’t have a place for images at all.  If the
> method is implemented, but returns nil, then a default image is used
> as a placeholder instead (in a view which has a place for images).
>
> tl;dr: Optional methods are often used as customization points,
> and the methods, if implemented, may also have another meaning/use
> for nil.
>
>
> Similarly, a different back-end implementation may be used in the case
> where an optional method is not implemented.  Let’s say you have
> something like a tableview with an optional method giving rowHeights.
> If that method is unimplemented, it is possible to have a much more
> efficient layout algorithm… and in some cases, you may check for the
> existence of the optional method when the delegate is set, and swap
> out a different layout object based on which customizations are needed
> (and again nil might mean that a height/etc... should be automatically
> calculated).  This is the ability I miss the most.
>
>
> Not saying the proposal is unworkable, just wanted to add some food
> for thought.  I know I really miss optional methods in Swift.  In some
> areas Swift is a lot more powerful, but there are lots of things I
> used to do in Obj C that I haven’t figured out how to do in Swift yet
> (if they are even possible).  I am kind of disturbed by the
> trend/desire to get rid of the smalltalk-ness, as opposed to finding
> new and safer ways to support that flexibility/expressiveness.  I
> would really like to see swift deliver on it’s promise of being a more
> modern alternative to ObjC (which it isn’t yet, IMHO) instead of just
> a more modern alternative to C++/Java.
>
> Thanks,
> Jon
>
>> Proposed Solution: Caller-side default implementations  Default
>> implementations and optional requirements differ most on the caller
>> side. For example, let’s use NSTableView delegate as it’s imported
>> today:  func useDelegate(delegate: NSTableViewDelegate) { if let
>> getView = delegate.tableView(_:viewFor:row:) { // since the
>> requirement is optional, a reference to the method produces a value
>> of optional function type // I can call getView here }  if let
>> getHeight = delegate.tableView(_:heightOfRow:) { // I can call
>> getHeight here } }  With my proposal, we’d have some compiler-
>> synthesized attribute (let’s call it
>> @__caller_default_implementation) that gets places on Objective-C
>> optional requirements when they get imported, e.g.,  @obj

Re: [swift-evolution] Ability to pack, order and align certain types of Structs (like in C)

[hitstergtd+swiftevo--- via swift-evolution]

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

I am uncertain as to what happens after Swift 3 since there doesn't seem
to be any guidelines for that; hopefully the above would ensure that
it isn't forgotten. :)

> On 8 April 2016 at 07:01, Chris Lattner  wrote:
>>
>>> On Apr 7, 2016, at 12:28 PM, hitstergtd+swiftevo--- via swift-evolution 
>>>  wrote:
>>>
>>> To the community:
>>>
>>> Neither am I a compiler/language design expert nor have I previously
>>> written a proposal to that effect, so I apologise if I have
>>> trivialised the matter especially with regard to other parts of Swift
>>> or if some of it already exists. I am also aware that what I've
>>> proposed herein maybe possible through alternate means. However, the
>>> aim of this is to make it a first-class feature in Swift itself. For
>>> those unfamiliar with what is being requested, please see [2], [5] and [8].
>>>
>>> I have also filed this as a language feature request at [7].
>>
>> Yes, this would be a great thing to have, but it requires significant design 
>> and implementation work, so I’m afraid it is out of scope for Swift 3.  In 
>> the meantime, a lame workaround is that you can define your struct in C and 
>> import it.  Swift will honor the layout of the C type.
>>
>> -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Shortcut for creating arrays

[Vladimir.S via swift-evolution]

On 08.04.2016 17:05, Ross O'Brien via swift-evolution wrote:

Well, you can do this already:
let words = "rats live on no evil star".componentsSeparatedByString(" ")
so I don't know how much a shortcut is needed.


Also thought about componentsSeparatedByString, clearly says what we have, 
what we do and what will have in result.

So I'm -1 for special command for such word array.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Thorsten Seitz via swift-evolution]

Am 08.04.2016 um 11:59 schrieb Brent Royal-Gordon :

>> I only wonder whether you really want to repeat Error() all over, possibly 
>> with `aString` etc. as argument.
> 
> `Error()`, no. `SpimsterKitError.invalidWicketField("a"`), yes, because even 
> if `Int.init(_:)` threw *an* error, it wouldn't throw *your* error.

That's why I thought that in a real use case that logic would likely be 
extracted.

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

Re: [swift-evolution] Shortcut for creating arrays

[James Campbell via swift-evolution]

Pehaps we could have a function that splits by whitespace.

"h j c k".split()

*___*

*James⎥Alex's Minder*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 8 April 2016 at 15:05, Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, you can do this already:
> let words = "rats live on no evil star".componentsSeparatedByString(" ")
> so I don't know how much a shortcut is needed.
>
> And given '%w' would currently be impossible in Swift as an operator
> containing a letter, is there a Swiftier function name or operator for this?
>
> On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hey guys,
>>
>> Very often we need to create an array strings. It's a routine task and I
>> really like shortcut in Ruby that shortcut makes everyday coding a little
>> bit easier and fun:
>>
>>words = %w[rats live on no evil star]
>>
>> What do you think about adding something like this in Swift?
>>
>> Cheers,
>> Arsen
>>
>> ___
>> 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] [RFC] New collections model: collections advance indices

[plx via swift-evolution]

> On Mar 8, 2016, at 11:49 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Tue Mar 08 2016, plx  > wrote:
> 
>>> On Mar 3, 2016, at 3:28 PM, Dmitri Gribenko 
>>> wrote:
>> 
>> I think it’s possible to adjust the protocol hierarchy to “reserve
>> room”—remove `Indexable`’s methods from `Collection`, add them back to
>> a new `ForwardCollection` between `Collection` and
>> `BidirectionalCollection`—but it’d only make sense to do that if you
>> expect to have use for that room in the future.
> 
> This is something we expressly don't do in generic programming.
> Protocols (concepts) are spawned only by the existence of real-world
> use-cases, and enough of them to make the generality worthwhile.

Apologies for the long delay in replying. I’ll keep this somewhat brief b/c:

- it’s been almost a month
- it’s perfectly-feasible for me to tack-on my own little hierarchy for my own 
needs, if necessary

…so even though I would personally *prefer* that `Collection` be defined as 
*having-a* canonical linearization (as opposed to *being-a* linearization), it 
doesn't seem to be of pressing concern.

I do, however, have an alternative proposal: would it be possible to have 
`Collection` support some methods like these (but with less-atrocious naming):

  // MARK: Basic “Unordered” Iteration

  /// Like `forEach`, but need not *necessarily* visit elements in the same 
order as you would
  /// see them in a for-in loop; meant for use for when all you need is to 
visit each element in *some* order.
  func unorderedForEach(@noescape visitor: (Self.Generator.Element) throws -> 
Void) rethrows

  /// Type of the sequence for `unorderedElements`; a default that is `== Self` 
seems reasonable.
  associatedtype UnorderedElementSequence: Sequence where 
UnorderedElementSequence.Generator.Element == Self.Generator.Element

  /// Returns a sequence that visits all elements in `self` in *some* order, 
but not
  /// necessarily the same order as a for-in loop (and not *necessarily* the 
same
  /// ordering as-in `unorderedForEach`…)
  func unorderedElements() -> UnorderedElementSequence

…and perhaps also some methods like these:

  // MARK: “Unordered” Enumeration (Index + Element)

  /// Like `unorderedForEach`, but the closure is given `(indexOfElement, 
element)` rather than
  /// just `element` itself; the name here is terrible in particular. No 
guarantee the ordering is
  /// the same as the ordering for unorderedForEach
  func unorderedEnumeratedForEach(@noescape visitor: 
(Self.Index,Self.Generator.Element) throws -> Void) rethrows

  /// Type of the sequence for `unorderedEnumeration `; a default that is 
identical to what `self.enumerate()` returns seems reasonable.
  associatedtype UnorderedEnumerationSequence: Sequence where 
UnorderedElementSequence.Generator.Element == 
(Self.Index,Self.Generator.Element)

  /// Returns a sequence that visits all pairs of `(indexOfElement, element) in 
`self` in *some* order, but not
  /// necessarily the same order as a for-in loop.
  func unorderedEnumeration() -> UnorderedEnumerationSequence

…?

If you want a motivating example, suppose you have a k-ary tree-like 
implemented as a packed array (in the usual way).

Obviously the “standard” for-in/index/etc. iteration should respect the “tree 
ordering”; but, if all you’re doing is this:

  // or `for view in contentViews`...
  contentViews.forEach() { $0.hidden = false }

…it’d be nice to be able to write something like this:

  // or `for view in contentViews.unorderedElements()`...
  contentViews.unorderedForEach() { $0.hidden = false } 

…to avoid paying the cost of visiting things in order?

For concrete types you can always define such methods and call them when 
appropriate, but I think it’d be very handy to have such methods available in 
generic contexts.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Shortcut for creating arrays

[Ross O'Brien via swift-evolution]

Well, you can do this already:
let words = "rats live on no evil star".componentsSeparatedByString(" ")
so I don't know how much a shortcut is needed.

And given '%w' would currently be impossible in Swift as an operator
containing a letter, is there a Swiftier function name or operator for this?

On Fri, Apr 8, 2016 at 2:20 PM, Arsen Gasparyan via swift-evolution <
swift-evolution@swift.org> wrote:

> Hey guys,
>
> Very often we need to create an array strings. It's a routine task and I
> really like shortcut in Ruby that shortcut makes everyday coding a little
> bit easier and fun:
>
>words = %w[rats live on no evil star]
>
> What do you think about adding something like this in Swift?
>
> Cheers,
> Arsen
>
> ___
> 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] [SR-933] Rename flatten to flattened

[Haravikk via swift-evolution]

> On 8 Apr 2016, at 12:00, Pyry Jahkola  wrote:
> 
> 
>> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I think it makes sense to just rename them; it’s not as though flattened or 
>> mapped is somehow far removed from the original meaning as the actual action 
>> is the same, it’s just changing tense.
> 
> -1, and not only for the reasons we neither call trigonometric functions 
> `sine`, `cosine`, and `tangent`. The existing names are widely known, 
> commonly taught in modern introductory programming courses, to the point, and 
> googleable.

I’m not sure if sine, cosine etc. are equivalent to the case of map, flatten 
and so-on? Are they not nouns rather than verbs?
I don’t think googleable should be that important; what’s important is what the 
method does, i.e- what you want to do, as long as it’s well described it should 
still be searchable, especially if there is a mutating equivalent that’s named 
in present tense.

> This idea of in-place versions is innocuous but absurd. In general, there's 
> no way mapping `T -> U` over a `[T]` could possibly accommodate the result in 
> the argument of type `[T]`:
> 
> var xs: [Int] = ...
> xs.mapInPlace {String($0)} // ???
> 
> And the same goes for `flatMap`, and `Optional` and others. Likewise, 
> `flatten()` couldn't possibly happen in place because the result type has one 
> level of nesting less than the argument.

True enough, didn’t think that through, though mapping where the type remains 
unchanged would be possible. Not really the point though, I think it should 
still be named consistently; if you make exceptions then why have guidelines on 
naming at all?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

[Haravikk via swift-evolution]

> On 8 Apr 2016, at 11:32, Brent Royal-Gordon  wrote:
> 
>> Can someone fill me in as to how this differs from (0…4).contains(x)?
>> 
>> Personally I don’t like the choice for the operator, and think it’s not very 
>> clear, if we can do the same thing with a method then I’d prefer removing 
>> the operator to be honest.
> 
> ~= is the way you customize how a type behaves when it's a pattern in a 
> switch statement. So ~= (_: Range, _: T) is responsible for making `case 
> 1..<10` work properly. Removing it would be…unwise.

But why not just (1..<10).contains(x) behind the scenes instead? This could be 
redefined as a protocol or whatever. It’s just kind of strange as an operator, 
and as the OP said not especially well known.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Shortcut for creating arrays

[Arsen Gasparyan via swift-evolution]

Hey guys,

Very often we need to create an array strings. It's a routine task and I
really like shortcut in Ruby that shortcut makes everyday coding a little
bit easier and fun:

   words = %w[rats live on no evil star]

What do you think about adding something like this in Swift?

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

Re: [swift-evolution] Limit checking syntax

[Vladimir.S via swift-evolution]

On 08.04.2016 4:14, Harlan Haskins via swift-evolution wrote:
> I’ve found that .contains works well for all my uses.
>
> (0..<100).contains(x)

Hmm.. Isn't next construction is much more readable?:

x.in(0..<100)

I think it is much more readable.
We are planning(in head) to verify "if x value is in range from 0 up to 
99", so why we have to write "for some range 0 to 9 let's check if it 
contains our x value".

Our x is a subject of our check, not range (0..<100).

I.e. in my opinion -1 for 'in' operator like suggested in initial message,
but +1 for .in method for integer to check against range
Any additional opinion?

Vladimir
(P.S. Sorry for duplicate.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Jonathan Hull via swift-evolution]

Interesting proposal, but I wanted to mention a couple of potential issues off 
the top of my head.  I know when I was using optional requirements in Objective 
C, I would often use the presence/lack of the method (not just whether it 
returned nil) in the logic of my program.  I used the presence of a method as a 
way for the implementor of a delegate to naturally communicate whether they 
wanted a more advanced feature.  The absence of the method itself is 
information which can be utilized, not just whether it returns nil, and I 
believe that is part of what people are asking for when they say they want 
optional methods in Swift.


Let me try to give a simplified example which I am not sure how you would work 
around in this proposal:

Let’s say there is a datasource protocol which optionally asks for an image 
associated with a particular piece of data (imagine a table or collection view 
type custom control).  If the method is not implemented in the data source, 
then a different view is shown for each data point that doesn’t have a place 
for images at all.  If the method is implemented, but returns nil, then a 
default image is used as a placeholder instead (in a view which has a place for 
images).

tl;dr: Optional methods are often used as customization points, and the 
methods, if implemented, may also have another meaning/use for nil.


Similarly, a different back-end implementation may be used in the case where an 
optional method is not implemented.  Let’s say you have something like a 
tableview with an optional method giving rowHeights.  If that method is 
unimplemented, it is possible to have a much more efficient layout algorithm… 
and in some cases, you may check for the existence of the optional method when 
the delegate is set, and swap out a different layout object based on which 
customizations are needed (and again nil might mean that a height/etc... should 
be automatically calculated).  This is the ability I miss the most.


Not saying the proposal is unworkable, just wanted to add some food for 
thought.  I know I really miss optional methods in Swift.  In some areas Swift 
is a lot more powerful, but there are lots of things I used to do in Obj C that 
I haven’t figured out how to do in Swift yet (if they are even possible).  I am 
kind of disturbed by the trend/desire to get rid of the smalltalk-ness, as 
opposed to finding new and safer ways to support that 
flexibility/expressiveness.  I would really like to see swift deliver on it’s 
promise of being a more modern alternative to ObjC (which it isn’t yet, IMHO) 
instead of just a more modern alternative to C++/Java.

Thanks,
Jon

> Proposed Solution: Caller-side default implementations
> 
> Default implementations and optional requirements differ most on the caller 
> side. For example, let’s use NSTableView delegate as it’s imported today:
> 
> func useDelegate(delegate: NSTableViewDelegate) {
>   if let getView = delegate.tableView(_:viewFor:row:) { // since the 
> requirement is optional, a reference to the method produces a value of 
> optional function type
> // I can call getView here
>   }
> 
>   if let getHeight = delegate.tableView(_:heightOfRow:) {
> // I can call getHeight here
>   }
> }
> 
> With my proposal, we’d have some compiler-synthesized attribute (let’s call 
> it @__caller_default_implementation) that gets places on Objective-C optional 
> requirements when they get imported, e.g.,
> 
> @objc protocol NSTableViewDelegate {
>   @__caller_default_implementation func tableView(_: NSTableView, viewFor: 
> NSTableColumn, row: Int) -> NSView?
>   @__caller_default_implementation func tableView(_: NSTableView, 
> heightOfRow: Int) -> CGFloat
> }
> 
> And “optional” disappears from the language. Now, there’s no optionality 
> left, so our useDelegate example tries to just do correct calls:
> 
> func useDelegate(delegate: NSTableViewDelegate) -> NSView? {
>   let view = delegate.tableView(tableView, viewFor: column, row: row)
>   let height = delegate.tableView(tableView, heightOfRow: row)
> }
> 
> Of course, the code above will fail if the actual delegate doesn’t implement 
> both methods. We need some kind of default implementation to fall back on in 
> that case. I propose that the code above produce a compiler error on both 
> lines *unless* there is a “default implementation” visible. So, to make the 
> code above compile without error, one would have to add:
> 
> extension NSTableViewDelegate {
>   @nonobjc func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) 
> -> NSView? { return nil }
>   
>   @nonobjc func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat { 
> return 17 }
> } 
> 
> Now, the useDelegate example compiles. If the actual delegate implements the 
> optional requirement, we’ll use that implementation. Otherwise, the caller 
> will use the default (Swift-only) implementation it sees. From an 
> implementation standpoint, the compiler would effectively produce the 
> fol

Re: [swift-evolution] [Proposal] Custom operators

[Rainer Brockerhoff via swift-evolution]

On 4/8/16 02:59, Chris Lattner via swift-evolution wrote:
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution 
>>  wrote:
>> Link for newcomers:
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>  
>> 
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in the 
>> beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I 
>> still have not heard anything from Core team.
> ... 
> I’m sorry for the delay, I have been out of town recently.  I haven’t read 
> the upstream thread so I hope this isn’t too duplicative.  Here is my 2c:
> 
> - I completely agree that numeric precedences are lame, it was always the 
> “plan” that they’d be removed someday, but that obviously still hasn’t 
> happened :-)

+10!

> - I definitely agree that a partial ordering between precedences is all that 
> we need/want, and that unspecified relations should be an error.
> ...
> Question for you: have you considered introducing named precedence groups, 
> and having the relationships be between those groups?  For example, I could 
> see something like:
> 
>   operator group additive {}
>   operator group multiplicative { greaterThan: additive }
>   operator group exponential { greaterThan: additive }

Also +10, would be interested in your opinion about:

1) disallowing adding new operator groups outside the stdlib;

2) disallowing adding operators to uncommon groups like subscripting,
function calls, etc.

TIA...
-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0064: Referencing the Objective-C selector of property getters and setters

[Sebastian Hagedorn via swift-evolution]

> What is your evaluation of the proposal?

+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. I agree with Michael Buckley that this feels more like an oversight in 
SE-0022 rather than a completely new thing.

> Does this proposal fit well with the feel and direction of Swift?
Yes. I think it makes sense to use explicit getter/setter parameter names, as 
opposed to relying on the ObjC-based foo/setFoo: conventions. While the lines 
between property accessors and methods are blurry in ObjC, they are different 
things in Swift. I’m aware that this feature requires ObjC under the hood, but 
that’s not something you need to know when creating a selector.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Well, ObjC… I’ve explained the difference above.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I’ve read the proposal and the previous review.

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

Re: [swift-evolution] [SR-933] Rename flatten to flattened

[Pyry Jahkola via swift-evolution]

> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution 
>  wrote:
> 
> I think it makes sense to just rename them; it’s not as though flattened or 
> mapped is somehow far removed from the original meaning as the actual action 
> is the same, it’s just changing tense.

-1, and not only for the reasons we neither call trigonometric functions 
`sine`, `cosine`, and `tangent`. The existing names are widely known, commonly 
taught in modern introductory programming courses, to the point, and googleable.

In addition:

> If we want mutating forms of this methods then I much prefer .map() and 
> .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts 
> the naming convention used everywhere else which only adds confusion.

This idea of in-place versions is innocuous but absurd. In general, there's no 
way mapping `T -> U` over a `[T]` could possibly accommodate the result in the 
argument of type `[T]`:

var xs: [Int] = ...
xs.mapInPlace {String($0)} // ???

And the same goes for `flatMap`, and `Optional` and others. Likewise, 
`flatten()` couldn't possibly happen in place because the result type has one 
level of nesting less than the argument.

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

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Vladimir.S via swift-evolution]

On 07.04.2016 21:43, Dmitri Gribenko wrote:

There would be no need to.  Collection will have a .successor(of:)
method that returns the next index after the given one.



I see. Thank you for letting know about this.


I can see that, but when you know that you are dealing with an
integer, isn't "+ 1" a more common and readable notation?


Hmm.. I believe that i++ is muuuch common used than i += 1 ;-)

Personally I totally agree with almost all reasons why we should drop these 
++/--, but until this moment I was not agree that operator(not expression) 
i++ (i.e. operator to increase i to 1 that do not return any value) 
produces any problem in code. And it is so common in programming word, in 
c/c++ which we will(!) use with our Swift code often, so it can't produce 
any misunderstanding like "what does this "i++" line do??"

(again, just operator, like: if something { someInt++ } )

But now, I was pointed that someInt += 1 is better because of this "=" char 
in operator i.e. we clearly say that we will assign the value to variable, 
mutate it.
And I think this makes the language better, so right now I fully support 
the decision to remove ++/--


So.. Thank you for your time and your replies :-)

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

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

[Brent Royal-Gordon via swift-evolution]

> Can someone fill me in as to how this differs from (0…4).contains(x)?
> 
> Personally I don’t like the choice for the operator, and think it’s not very 
> clear, if we can do the same thing with a method then I’d prefer removing the 
> operator to be honest.

~= is the way you customize how a type behaves when it's a pattern in a switch 
statement. So ~= (_: Range, _: T) is responsible for making `case 1..<10` 
work properly. Removing it would be...unwise.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

[Haravikk via swift-evolution]

Can someone fill me in as to how this differs from (0…4).contains(x)?

Personally I don’t like the choice for the operator, and think it’s not very 
clear, if we can do the same thing with a method then I’d prefer removing the 
operator to be honest.

> On 7 Apr 2016, at 12:57, David Rodrigues via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Swift has a pattern match operator, ~=, which is unknown to many (like me 
> until a few weeks ago), that performs a match between a value and a certain 
> pattern, e.g. checking if an integer value is contained in a range of 
> integers.
> 
> This operator may be little known, but it plays a key role in the language 
> since it's used behind the scenes to support expression patterns in `switch` 
> statement case labels, which we all know are extremely popular.
> 
> let point = (2, 4)
> switch point {
> case (0, 0):
> print("The point is at the origin")
> case (0...4, 0...4):
> print("The point is in the subregion")
> default:
> break
> }
> 
> Most of the time we don't use the operator directly but it is available and 
> can be handy in certain conditions.
> 
> let point = (2, 4)
> switch point {
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y:
> print("The point is in the subregion")
> default:
> break
> }
> 
> However the current syntax is not ideal (in my opinion). We're not really 
> declaring the operation that we want to do, and that has an impact in the 
> expressivity and readability of the code. Currently we're doing matches like 
> "if blue is the ocean" instead of "if the ocean is blue" or "if the ocean 
> contains the whale" instead of "if the whale is in the ocean".
> 
> For that reason, I would like to suggest inverting the order of the operator 
> to match more closely our logical thought.
> 
> case (let x, let y) where x =~ 0...4 && y =~ 0...4: // Proposed
> // vs
> case (let x, let y) where 0...4 ~= x && 0...4 ~= y: // Current
> 
> I have an ongoing proposal to suggest this change and it contains a little 
> more context. It is available here: 
> 
> https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/-invert-order-of-pattern-match-operator.md
>  
> .
> 
> Any feedback is very welcome.
> 
> Thank you.
> 
> David Rodrigues
> ___
> 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] [SR-933] Rename flatten to flattened

[Haravikk via swift-evolution]

> On 7 Apr 2016, at 19:12, Dave Abrahams via swift-evolution 
>  wrote:
> 
> We kept flatten as is because it is part of a suite of methods that are terms 
> of art from functional programming (map, filter, flatMap, reduce) that don't 
> follow the naming guidelines

I think it makes sense to just rename them; it’s not as though flattened or 
mapped is somehow far removed from the original meaning as the actual action is 
the same, it’s just changing tense.

For users coming to Swift as a first language I think that consistent naming is 
more important, and while terms of art are useful, it’s not as if changing the 
tense is changing the meaning or making them hard to find; anyone that types 
myArray.map… will have Xcode present them with .mapped. If we want mutating 
forms of this methods then I much prefer .map() and .mapped() to .map() and 
.mapInPlace() or whatever, as the latter contradicts the naming convention used 
everywhere else which only adds confusion.

Besides, I’d say the terms of art in these cases are more about what the basic 
operation does, whether or not the method manipulates the original is something 
that a developer should really check, i.e- when I look for .map in a new 
language I’m looking for a transformation method, I’ll then check what exactly 
that transformation does to the original collection. Plus features like unused 
result and type checks should keep people right about wether they’re using it 
correctly, so any mistake should be caught pretty easily.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Brent Royal-Gordon via swift-evolution]

> I only wonder whether you really want to repeat Error() all over, possibly 
> with `aString` etc. as argument.

`Error()`, no. `SpimsterKitError.invalidWicketField("a"`), yes, because even if 
`Int.init(_:)` threw *an* error, it wouldn't throw *your* error.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Thorsten Seitz via swift-evolution]

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Brent Royal-Gordon via swift-evolution]

> At the risk of asking one of those newbie questions, why bother with StrideTo 
> and StrideThrough? Isn't a Generator or Array more to the point?

You don't want to return an Array because you want to generate the values 
lazily. If `stride(over: 1..<1_000_000, by: 10)` returned an Array, you would 
have to allocate an array with 100,000 elements. A StrideTo, by contrast, is 
the size of roughly 3 elements; it creates the values on demand.

You can't return Generator because Generator is a protocol with no real 
behavior associated with it; you need a concrete type. StrideTo and 
StrideThrough conform to Sequence, a protocol whose main purpose is to return a 
Generator. (well, Iterator in Swift 3). So in essence, StrideTo and 
StrideThrough *are* how you return a Generator.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Limit checking syntax

[Thorsten Seitz via swift-evolution]

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

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Goffredo Marocchi via swift-evolution]

Proposal sounds nice, but shouldn't it go hand in hand with the review of 
dispatching rules for protocol extensions (i.e.: dynamic dispatch by default 
unless overridden by a user declaration/annotation or when the compiler is sure 
no side effects will occur... ProtocolA and InstanceAImplementingProtocolA must 
behave the same when calling a method)?
In a type safe language, the lack of safety current complex dispatching rules 
bring seems odd not to address :/. Sorry for the aside rant.

[[iOS messageWithData:ideas] broadcast]

> On 8 Apr 2016, at 01:12, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Optional protocol requirements in Swift have the restriction that they only 
> work in @objc protocols, a topic that’s come up a number of times. The start 
> of these threads imply that optional requirements should be available for all 
> protocols in Swift. While this direction is implementable, each time this is 
> discussed there is significant feedback that optional requirements are not a 
> feature we want in Swift. They overlap almost completely with default 
> implementations of protocol requirements, which is a more general feature, 
> and people seem to feel that designs based around default implementations and 
> refactoring of protocol hierarchies are overall better.
> 
> The main concern with removing optional requirements from Swift is their 
> impact on Cocoa: Objective-C protocols, especially for delegates and data 
> sources, make heavy use of optional requirements. Moreover, there are no 
> default implementations for any of these optional requirements: each caller 
> effectively checks for the presence of the method explicitly, and implements 
> its own logic if the method isn’t there.
> 
> A Non-Workable Solution: Import as optional property requirements
> One suggestion that’s come up to map an optional requirement to a property 
> with optional type, were “nil” indicates that the requirement was not 
> satisfied. For example, 
> 
> @protocol NSTableViewDelegate
> @optional
> - (nullable NSView *)tableView:(NSTableView *)tableView 
> viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row;
> - (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row;
> @end
> 
> currently comes in as
> 
> @objc protocol NSTableViewDelegate {
>   optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) 
> -> NSView?
>   optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
> }
> 
> would come in as:
> 
> @objc protocol NSTableViewDelegate {
>   var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) -> 
> NSView?)? { get }
>   var tableView: ((NSTableView, heightOfRow: Int) -> CGFloat)? { get }
> }
> 
> with a default implementation of “nil” for each. However, this isn’t 
> practical for a number of reasons:
> 
> a) We would end up overloading the property name “tableView” a couple dozen 
> times, which doesn’t actually work.
> 
> b) You can no longer refer to the member with a compound name, e.g., 
> “delegate.tableView(_:viewFor:row:)” no longer works, because the name of the 
> property is “tableView”.
> 
> c) Implementers of the protocol now need to provide a read-only property that 
> returns a closure. So instead of
> 
> class MyDelegate : NSTableViewDelegate {
>   func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) -> NSView? 
> { … }
> }
> 
> one would have to write something like
> 
> class MyDelegate : NSTableViewDelegate {
>   var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) -> 
> NSView?)? = {
> … except you can’t refer to self in here unless you make it lazy ...
>   }
> }
> 
> d) We’ve seriously considered eliminating argument labels on function types, 
> because they’re a complexity in the type system that doesn’t serve much of a 
> purpose.
> 
> One could perhaps work around (a), (b), and (d) by allowing compound 
> (function-like) names like tableView(_:viewFor:row:) for properties, and work 
> around (c) by allowing a method to satisfy the requirement for a read-only 
> property, but at this point you’ve invented more language hacks than the 
> existing @objc-only optional requirements. So, I don’t think there is a 
> solution here.
> 
> Proposed Solution: Caller-side default implementations
> 
> Default implementations and optional requirements differ most on the caller 
> side. For example, let’s use NSTableView delegate as it’s imported today:
> 
> func useDelegate(delegate: NSTableViewDelegate) {
>   if let getView = delegate.tableView(_:viewFor:row:) { // since the 
> requirement is optional, a reference to the method produces a value of 
> optional function type
> // I can call getView here
>   }
> 
>   if let getHeight = delegate.tableView(_:heightOfRow:) {
> // I can call getHeight here
>   }
> }
> 
> With my proposal, we’d have some compiler-synthesized attribute (let’s call 
> it @__caller_default_implementation) that gets places on Objective-C optional 
> r