Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

[Dave via swift-evolution]

What about enforcing the argument labels, but then adding a “@autolabel” or 
something in code where the current behavior is desired?

- Dave Sweeris

> On Apr 20, 2016, at 12:47 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> I think it's good that the labels aren't enforced:
> This would sacrifice flexibility, and force us to write unnecessary 
> boilerplate to "translate" labels (one library might use (height, width), and 
> another (h, w) to express the same concept…)
> 
> But: Objective-C had no tuples, so a final decision shouldn't happen until 
> there is an agreement on best-practices for them...
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Dave via swift-evolution]

> On Apr 20, 2016, at 1:15 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Apr 19 2016, Thorsten Seitz  wrote:
> 
>> I'd like to have something like Summable with 'add', 'adding' and 'zero' 
>> being a
>> separate protocol as well as somthing like Multiplicative with 'multiply',
>> 'multiplied' and 'one' being a separate protocol, because these are 
>> universally
>> interesting for other cases, e.g. Summable would be useful for defining path
>> lengths in a graph library.
>> 
>> Would you mind adding that to the proposal?
> 
> I suspect you may be headed into the realm of
> protocols-as-bags-of-syntax.
You say that like it’s a bad thing… Am I missing the point? (NOT a rhetorical 
question)

Speaking only for myself, I want stuff broken up into many simpler protocols 
(which `Arithmetic` and such conform to) because there are many algorithms 
which only require small parts of the larger protocol. What if I wanted to add 
a function that sums all the elements in a collection?
extension CollectionType where Generator.Element: Arithmetic {
func sum() -> Generator.Element {
var s = Generator.Element()
for e in self {
s.add(e)
}
return s
}
}

Yeah, it works, but if I want to get the sum of a collection of some custom 
type, I have to implement *all* of `Arithmetic`, as opposed to just the two 
parts of it (`init()` and `.add(:)`) that the algorithm actually uses. It’d be 
both simpler for the users and *more to the point of the function*, if it could 
be written like this:
extension CollectionType where Generator.Element: Addable { // "Addable" 
instead of "Arithmetic"
... // No change here
}

Now, if Swift allowed you to add protocol conformance to protocols:
protocol Addable {
... // Relevant subset of `Arithmetic`
}
#for T in Arithmetic { // "#for" because this is clearly macro-ish, and # seems 
to be what we've settled on for that
extension T : Addable {} // Don't need anything here since `Arithmetic` 
already has everything in `Addable`
}
… then this all becomes a somewhat moot point. If some generic function only 
needs a subset of a protocol’s functionality, said function’s author could do 
this “#for T …” song & dance, and their function would be defined with the 
minimum constraints.


> Look at pages 14 and 24 of
> —which does the job
> right for C++—and you'll see why.
COOL!!! Thanks for posting that, it looks like it’ll be a great read! :-D

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

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Dave via swift-evolution]

> On Apr 16, 2016, at 12:10 PM, Patrick Gili via swift-evolution 
>  wrote:
> 
> As an alternative, could we require the parens on the return. For example:
> 
> (Int) -> (Float)
> (String) -> ()
> () -> ()
> () -> (Double)
> 
> This looks cleaner, improves consistency, and simplifies the syntax (i.e., no 
> need to remember when parens are necessary).
> 
> -Patrick

I’m not sure it’s “cleaner” per se, but I agree with the rest. My earlier +1 
may have been premature…

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

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Dave via swift-evolution]

So, `Void->Int` functions would work like this?
let foo = bar(()) // returns Int

> On Apr 15, 2016, at 3:23 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> What I think we *should* eliminate, however, is using `Void` to mean "no 
> arguments" in a closure type. `Void -> Int` should mean that the type takes 
> one argument which happens to be an empty tuple. If you want no arguments, 
> write `() -> Int`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Dave via swift-evolution]

> On Apr 15, 2016, at 12:40 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Apr 14, 2016, at 10:28 PM, Chris Lattner  wrote:
>> 
>> In many places in the Swift grammar we aim for consistency, even if it means 
>> a bit more punctuation in specific cases.
> 
> This is not greatly in evidence.  We have a lot of special-case syntax.

I could’ve sworn I saw “getting rid of special-case syntax” as a general goal 
somewhere. Maybe I’m thinking of something else.

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

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Dave via swift-evolution]

+1

> On Apr 14, 2016, at 11:57 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> We currently accept function type syntax without parentheses, like:
> 
>  Int -> Float
>  String -> ()
> 
> etc.  The original rationale aligned with the fact that we wanted to treat 
> all functions as taking a single parameter (which was often of tuple type) 
> and producing a tuple value (which was sometimes a tuple, in the case of void 
> and multiple return values).  However, we’ve long since moved on from that 
> early design point: there are a number of things that you can only do in a 
> parameter list now (varargs, default args, etc), implicit tuple splat has 
> been removed, and  the compiler has long ago stopped modeling function 
> parameters this way.  Beyond that, it eliminates one potential style war.
> 
> Given all this, I think it makes sense to go for syntactic uniformity between 
> parameter list and function types, and just require parenthesis on the 
> argument list.  The types above can be trivially written as:
> 
>  (Int) -> Float
>  (String) -> ()
> 
> Thoughts?
> 
> -Chris
> ___
> 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

[Dave via swift-evolution]

“|” often means “with” in math, which is only one word off from “with step”.
func |  (range: Range, stride: 
T.Stride) -> IntegerStrideTo {
return IntegerStrideTo(_start: range.startIndex, end: range.endIndex, 
stride: stride)
}
var arr = [Int]()
for i in (0 ..< 10) | 2 {
arr.append(i)
}
arr //[0,2,4,6,8]

I couldn’t figure out how to do it without the parens… everything I could think 
to try is determined to parse as `(0) ..< (10 | 2)`, so `arr` ends up equalling 
[0,1,2,3,4,5,6,7,8,9]. If operator precedence and associativity were 
per-function rather than per-op, it could be made to work without the ().

- Dave Sweeris

> On Apr 14, 2016, at 8:27 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> That means we would need an expression along the lines of:
> 
>   1..<10 by 2
> 
> Which could be used anywhere. Unfortunately, Swift does not allow word 
> characters in identifiers, so `by` as an operator is a non-starter. I can't 
> think of a non-letter operator for `by` that would make sense, so we're 
> probably not going to go that route, either (but if you have a 
> suggestion—preferably one backed by existing notation from, say, math—by all 
> means suggest it).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TreeLiteralConvertible

[Dave via swift-evolution]

The topic’s come up before. I’m in favor of it, but IIRC there are two problems 
that need to be resolved first:

(I *think* I’m remembering this correctly… don’t quote me on this…)

First, it can cause the type-checker to become “pathological”.
Second, it can cause some *very* unexpected behavior if things are implicitly 
converted through different types than you thought.

- Dave Sweeris

> On Apr 14, 2016, at 4:24 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon  
>> wrote:
>>> No, you just need Tree to conform to both ArrayLiteralConvertible and 
>>> IntegerLiteralConvertible, and it implements the latter by building a Value 
>>> out of it.
>> 
>> That not only doesn't work if your type isn't a LiteralConvertible, it also 
>> doesn't work if you want to build a literal with variables:
>> 
>>  let myTree: Tree = [1, [2, three]]
>> 
>> The real missing feature here is implicit lifting like Optional offers. With 
>> a LiftingConvertible protocol, you could say something like this:
>> 
>>  enum Tree {
>>  case leaf(Value)
>>  case branches([Tree])
>>  }
>>  
>>  extension Tree: ArrayLiteralConvertible {
>>  init(arrayLiteral branches: Tree...) {
>>  self = .branches(branches)
>>  }
>>  }
>>  
>>  extension Tree: LiftingConvertible {
>>  init(lifting value: Value) {
>>  self = .leaf(value)
>>  }
>>  }
> 
> Another name for this feature is "user-defined implicit conversions".
> 
> John.
> ___
> 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] TreeLiteralConvertible

[Dave via swift-evolution]

I think a better solution than just adding a TreeLiteral (and the accompanying 
TreeLiteralConvertible protocol) would be to allow user-defined literal types 
using regex (or something similar). This would not only allow for tremendous 
flexibility, but it’d remove some compiler magic as well.

There’d have to be some rules regarding overlapping definitions… The simplest I 
can think of is make it an error to not do type annotation when there’s more 
than one way to parse a literal, but I’m not sure that’s necessarily the best.

- Dave Sweeris

> On Apr 14, 2016, at 11:27 AM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> In Swift, we cannot compile:
> 
> _ = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]]
> 
> The reason for the compile-time error is that we are not in fact creating an 
> array, but a tree – a more general structure of which arrays are only a 
> special case. Given the well-deserved and growing reputation of Swift, one 
> would hope that in this instance the compiler would be able to default to 
> something like a:
> 
> enum Tree {
>   case Leaf(Value)
>   case Branches([Tree])
> }
> 
> extension Tree : ArrayLiteralConvertible {
>   init(arrayLiteral elements: Tree...) {
>   self = .Branches(elements)
>   }
> }
> 
> For this to work in the playground, however, we must manually lift the values 
> into the world of trees first. And to make that chore in turn easier on the 
> eye we can introduce a:
> 
> prefix operator ◊ {} // looks a bit like a leaf (us/uk kbd: ⎇⇧V)
> prefix func ◊  (leaf: T) -> Tree { return .Leaf(leaf) }
> 
> let tree: Tree = [[], ◊1, [◊2, ◊3], [[◊4, ◊5], [◊6, ◊7], [◊8, ◊9]]]
> 
> The point here is that if adding such a fundamental type to the Standard 
> Library would not be a priority at present, it is not the end of the world 
> since we can easily enough write it ourselves… What we cannot do ourselves, 
> however, is to get rid of the need for that operator in the common scenario 
> of initialising with literal values. For this we need a literal-convertible 
> protocol requiring two initialisers:
> 
> protocol TreeLiteralConvertible {
>   associatedtype LeafValue
>   init(literal: Self.LeafValue...)
>   init(literal: Self...)
> }
> 
> Then we could simply:
> 
> let tree: Tree = [[], 1, [2, 3], [[4, 5], [6, 7], [8, 9]]]
> 
> And, whilst we are at it, we could also get rid of the need for that operator 
> in the case of nested associative arrays (again, you can try this in the 
> playground):
> 
> enum DictionaryTree {
>   case Leaf(Value)
>   case Branches([(Key, DictionaryTree)])
> }
> 
> extension DictionaryTree : DictionaryLiteralConvertible {
>   init(dictionaryLiteral pairs: (Key, DictionaryTree)...) {
>   self = .Branches(pairs)
>   }
> }
> 
> prefix func ◊  (leaf: Value) -> DictionaryTree { 
> return .Leaf(leaf) }
> 
> let map: DictionaryTree = [
>   "A" : [:],
>   "B" : [
>   "Ba" : ◊0,
>   "Bb" : ◊0,
>   "Bc" : [
>   "Bc1" : ◊0,
>   "Bc2" : ◊0,
>   "Bc3" : ◊0
>   ]
>   ]
> ]
> 
> … by introducing an analogous protocol:
> 
> protocol DictionaryTreeLiteralConvertible {
>   associatedtype Key
>   associatedtype LeafValue
>   init(literal: Self.LeafValue...)
>   init(literal: (Key, Self)...)
> }
> 
> Please note: I do understand that fleshing out these structures (along with 
> all the juicy methods, operators and lazy alternatives) may not currently be 
> a priority for Swift. The two literal-convertible protocols however, may be a 
> much less daunting task, which would open to us some very useful programming 
> idioms…
> 
> milos
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] mapValues

[Dave via swift-evolution]

“map” already "maps the values” so I think something like “transform” might be 
a little clearer, if we don’t want to just overload “map”. Regardless of what 
it’s called, though, I’m +1 on the functionality.

- Dave Sweeris

> On Apr 13, 2016, at 1:41 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would really like to see something like the following added to the standard 
> library:
> 
> extension Dictionary {
> 
> func mapValues(transform:(Key,Value)->U)->[Key:U] {
> var output:[Key:U] = [:]
> for (k,v) in self {
> output[k] = transform(k,v)
> }
> return output
> }
> 
> }
> 
> It comes up enough that I have had to add it to pretty much every one of my 
> projects.  I also don’t feel comfortable adding it to my frameworks, since I 
> figure a lot of people are also adding something like this to their projects, 
> and I don’t want to cause a conflict with their version.  Prime candidate for 
> the standard library.
> 
> I like calling it ‘mapValues' as opposed to providing an override for map, 
> since it makes the specific behavior more clear.  I would expect ‘map' to 
> possibly map the keys as well (though there are issues where the new keys 
> overlap).  I suppose you could just have a bunch of overrides for map if the 
> compiler becomes good enough at differentiating return types: 
> (Value)->(Value), (Key,Value)->Value, (Key, Value)->(Key,Value)
> 
> Thanks,
> Jon
> ___
> 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

[Dave via swift-evolution]

What about this? I’m unfamiliar with the details of objc-swift 
interoperability, so I’m not actually sure it could work this way, nor am I 
certain that I’m not just “rephrasing” something that’s already been suggested.
protocol SomeProtocol {
//Non-optional stuff goes here
}
extension SomeProtocol {
//Optional stuff goes here
func blah() {
//Default implementation goes here
}
}

protocol SomeSubProtocol : SomeProtocol {
//The same optional stuff goes here again
func blah()
}

func foo (x:T) {
if let x = x as? SomeSubProtocol {
x.blah() //Is custom implementation because we know x is 
SomeOtherProtocol
} else {
x.blah() //Is default implementation because we know it's not
}
...
}

(It seems like there ought to be a less repetitive way to do the branch. The 
problem is that any expression would necessarily have to evaluate to two 
different types, depending on whether T conforms to the sub protocol.)

Anyway, does that correctly model the relationship between optional 
requirements and their protocols? I’ve used optional protocol requirements just 
enough to use UIKit and such, but I find the whole self-contradictional 
"optional requirement” thing confusing enough that I’ve never really felt like 
I understand them. There’s a fair chance that I’m missing their point.

If that is the correct model, is there a way to automatically create all the 
objc “subprotocols" as they’re being imported into swift? If so, would it be 
beneficial to maybe “nest” the protocols to prevent UIKit from declaring 50 
million “top level” protocols?
protocol SomeProtocol {
protocol SomeOtherProtocol { // the " : SomeProtocol" part is implied
func blah() -> Int
}
//Non-optional stuff goes here
}
extension SomeProtocol {
//Optional stuff goes here
func blah() -> Int {
return 5
}
}
func blah (x:T) -> Int {
if let x = x as? SomeProtocol.SomeOtherProtocol {…}
}

- Dave Sweeris

> On Apr 13, 2016, at 12:47 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Apr 8, 2016, at 8:53 AM, Shawn Erickson > > wrote:
>> 
>> 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.
> 
> Just to be very clear (which I think my initial post wasn’t) my proposal does 
> *not* break this optimization when a Swift class is conforming to an @objc 
> protocol: even if a default is present, it won’t be visible to the 
> Objective-C runtime at all.
> 
> My proposal *does* make it significantly harder to implement a check for “did 
> the type implement this method?”, because one will effectively have to use 
> -respondsToSelector:. For Cocoa-defined delegates, that doesn’t matter at 
> all: apps generally implement requirements of delegates/data sources, but 
> almost never go through the protocol to use those methods/properties. It’s 
> the frameworks that do the calling, and of course they’re already using 
> -respondsToSelector: checks.
> 
> The main effect is in Swift code that uses @objc optionals and tests for the 
> absence of an implementation to perform some optimization. The tenor of the 
> previous thread seems to indicate that this probably isn’t common, because 
> there are probably better ways to model these cases in Swift—whether it’s 
> with multiple protocols or something that specifically describes the policy 
> (e.g., 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13347/focus=13480 
> ).
> 
> 
>> 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.
> 
> The direction I’m trying to go is not to have half of a feature—something 
> that seems like it should be general, but is tied to 

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

[Dave via swift-evolution]

I understand (and agree with) 3/4 of that… Why do we want to prevent striding 
*to* an infinity? I mean, yeah it’ll take a long time to get there, but with 
the new floating point stride code, a floating point value will *eventually* 
“overflow” into infinity (or `iteration += 1` will overflow and crash), it’s 
just that at that point there isn’t a straight-forward way to go the other 
direction anymore.

Actually, striding from an infinity should be ok, too, as long as it’s not the 
actual starting point:
let x = -Double.infinity ... 0.0 // Big Problems in, um, Non-Little Loops… or 
something… (and apologies to Kurt Russell)
let x = -Double.infinity <.. 0.0 // starts at `nextafter(start, end)` 
(-1.797693134862316e+308, in this case)

If the infinities are definitely out even as exclusive endpoints, can the 
floating point types get min/max properties like the integer types have?
let x = Double.min ... Double.max // same as -1.797693134862316e+308 ... 
1.797693134862316e+308, but way easier to write
let x = Float.min ... Float.max // same as -3.402823e+38 ... 3.402823e+38

- Dave Sweeris

> On Apr 10, 2016, at 12:05 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> We will be proposing exactly that which you've put in parentheses, i.e. 
> floating point types will get their own strides, and it will be a 
> precondition failure to try to stride from or to infinity or nan :)
> 
> On Sun, Apr 10, 2016 at 4:47 AM <daveswee...@mac.com 
> <mailto:daveswee...@mac.com>> wrote:
> It’s not a matter of floating point error accumulation… At least on my 
> machine, once a Double hits +/-∞, there’s no way that I know of to get back 
> to normal floating point numbers. That is to say, for *all* normal, finite 
> values of x, "-Double.infinity + x" will just return “-inf". If x is to equal 
> Double.infinity, Double.NaN, or Double.quietNaN, then it’ll return “nan” 
> (which, incidentally, will fail the regular equality test… Double.NaN isn’t 
> even equal to itself; I think checking the floating point class is the way to 
> do it).
> 
> I could easily be missing something, but AFAICT the only way to always get 
> the correct sequence (without splitting the floating point types off into 
> their own thing) is either have a negative stride swap start and end *before* 
> the StrideTo starts generating values (that is, *not* by just calling 
> `.reverse()` on something with a positive stride), or to allow “0 ..< 
> -Double.infinity” to be a valid range (with the negative stride being 
> implied).
> 
> - Dave Sweeris
> 
>> On Apr 9, 2016, at 6:59 PM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> Yikes. Not too concerned about the infinite loop issue, as floating point 
>> strides when fixed to avoid error accumulation will necessarily enforce a 
>> finite number of steps. However, you're talking a regular, not-at-all-lazy 
>> Array being returned? That would be not good at all...
>> 
>> On Sun, Apr 10, 2016 at 12:29 AM Dave via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> While I’m in favour of the basic idea I think the operator selection is too 
>>> complex, and I’m not sure about the need for negative strides. Really all I 
>>> want are the following:
>>> 
>>> (0 ... 6).striding(by: 2)   // [0, 2, 4, 6] x from 0 to 6
>>> (0 ..< 6).striding(by: 2)   // [0, 2, 4]x from 0 while 
>>> <6
>>> (6 ... 0).striding(by: 2)   // [6, 4, 2, 0] x from 6 to 0
>>> (6 ..> 0).striding(by: 2)   // [6, 4, 2]x from 6 while 
>>> >0
>>> 
>>> Everything else should be coverable either by flipping the order, or using 
>>> .reverse(). The main advantage is that there’s only one new operator to 
>>> clarify the 6 ..> 0 case, though you could always just reuse the existing 
>>> operator if you just interpret it as “x from 6 to, but not including, 0"
>> 
>> `.reverse()` returns an array, though, not a StrideTo<>, which means it’ll 
>> get in an infinite loop on infinite sequences. This works fine:
>> for i in stride(from: 0.0, to: Double.infinity, by: M_PI) {
>> if someTestInvolving(i) { break }
>> ...
>> }
>> 
>> But this never even starts executing the loop because of the infinite loop 
>> inside `.reverse()`:
>> for i in stride(from: -Double.infinity, to: 0.0, by: M_P

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

[Dave via swift-evolution]

Oh, right, we’re talking about Swift 3.0… I really need to get that up and 
running on my computer.


> On Apr 9, 2016, at 8:58 PM, Dave Abrahams  wrote:
> 
> 
> on Sat Apr 09 2016, davesweeris-AT-mac.com wrote:
> 
>>On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution
>> wrote:
>> 
>>While I’m in favour of the basic idea I think the operator selection is 
>> too
>>complex, and I’m not sure about the need for negative strides. Really all 
>> I
>>want are the following:
>> 
>>(0 ... 6).striding(by: 2) // [0, 2, 4, 6] x from 0 to 6
>>(0 ..< 6).striding(by: 2) // [0, 2, 4] x from 0 while <6
>>(6 ... 0).striding(by: 2) // [6, 4, 2, 0] x from 6 to 0
>>(6 ..> 0).striding(by: 2) // [6, 4, 2] x from 6 while >0
>> 
>>Everything else should be coverable either by flipping the order, or 
>> using .
>>reverse(). The main advantage is that there’s only one new operator to
>>clarify the 6 ..> 0 case, though you could always just reuse the existing
>>operator if you just interpret it as “x from 6 to, but not including, 0"
>> 
>> `.reverse()` returns an array, though, not a StrideTo<>, 
> 
> .reversed() returns a ReversedCollection when the underlying collection
> is bidirectional:
> 
> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Reverse.swift#L250
> 
> That's lazy and cheap.
> 
>> which means it’ll get in an infinite loop on infinite sequences. 
>> This works fine: for i in stride(from: 0.0, to: Double.infinity, by:
>> M_PI) { if someTestInvolving(i) { break } ...  }
>> 
>> But this never even starts executing the loop because of the infinite loop
>> inside `.reverse()`:
>> for i in stride(from: -Double.infinity, to: 0.0, by: M_PI).reverse() {
>> if someTestInvolving(i) { break }
>> ...
>> }
>> 
>> - Dave Sweeris
>> 
> 
> -- 
> Dave

___
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

[Dave via swift-evolution]

It’s not a matter of floating point error accumulation… At least on my machine, 
once a Double hits +/-∞, there’s no way that I know of to get back to normal 
floating point numbers. That is to say, for *all* normal, finite values of x, 
"-Double.infinity + x" will just return “-inf". If x is to equal 
Double.infinity, Double.NaN, or Double.quietNaN, then it’ll return “nan” 
(which, incidentally, will fail the regular equality test… Double.NaN isn’t 
even equal to itself; I think checking the floating point class is the way to 
do it).

I could easily be missing something, but AFAICT the only way to always get the 
correct sequence (without splitting the floating point types off into their own 
thing) is either have a negative stride swap start and end *before* the 
StrideTo starts generating values (that is, *not* by just calling `.reverse()` 
on something with a positive stride), or to allow “0 ..< -Double.infinity” to 
be a valid range (with the negative stride being implied).

- Dave Sweeris

> On Apr 9, 2016, at 6:59 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Yikes. Not too concerned about the infinite loop issue, as floating point 
> strides when fixed to avoid error accumulation will necessarily enforce a 
> finite number of steps. However, you're talking a regular, not-at-all-lazy 
> Array being returned? That would be not good at all...
> 
> On Sun, Apr 10, 2016 at 12:29 AM Dave via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> While I’m in favour of the basic idea I think the operator selection is too 
>> complex, and I’m not sure about the need for negative strides. Really all I 
>> want are the following:
>> 
>>  (0 ... 6).striding(by: 2)   // [0, 2, 4, 6] x from 0 to 6
>>  (0 ..< 6).striding(by: 2)   // [0, 2, 4]x from 0 while 
>> <6
>>  (6 ... 0).striding(by: 2)   // [6, 4, 2, 0] x from 6 to 0
>>  (6 ..> 0).striding(by: 2)   // [6, 4, 2]x from 6 while 
>> >0
>> 
>> Everything else should be coverable either by flipping the order, or using 
>> .reverse(). The main advantage is that there’s only one new operator to 
>> clarify the 6 ..> 0 case, though you could always just reuse the existing 
>> operator if you just interpret it as “x from 6 to, but not including, 0"
> 
> `.reverse()` returns an array, though, not a StrideTo<>, which means it’ll 
> get in an infinite loop on infinite sequences. This works fine:
> for i in stride(from: 0.0, to: Double.infinity, by: M_PI) {
> if someTestInvolving(i) { break }
> ...
> }
> 
> But this never even starts executing the loop because of the infinite loop 
> inside `.reverse()`:
> for i in stride(from: -Double.infinity, to: 0.0, by: M_PI).reverse() {
> if someTestInvolving(i) { break }
> ...
> }
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

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

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

[Dave via swift-evolution]

> On Apr 9, 2016, at 5:58 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 9 Apr 2016, at 10:50, Xiaodi Wu > > wrote:
>> 
>> But, ranges are useful for more than just stride, and so I would say it 
>> doesn't make sense to have an intrinsic direction for Range, which pointedly 
>> has lowerBound and upperBound but not start and end. For sample, there 
>> shouldn't be (0...9).contains(1) and (9...0).contains(1).
> 
> While I can appreciate that, I wonder if it’s really that important that 0…9 
> and 9…0 are identical? As long as we can be clear on which direction of range 
> we want to generate (so probably still need two new operators), can tell what 
> the direction is, and can convert between them if we need to for some reason 
> (reverse should be fine for that?), then I think we’re okay.
> 
> i.e- 9 … 0 would still cause an error at compile or run-time, we’d have some 
> other operator for doing that, not sure what, plus 9 ..> 0, with both 
> explicitly creating ranges in the reverse direction to avoid mistakes with 
> the order or for computed indices. When it comes down to it the current Range 
> has an implicitly forward direction, so I don’t see the problem with having 
> the same in reverse personally.
> 
> 
> I dunno, at the very least we might want to consider overloading the striding 
> method as .striding(forwardBy:) and .striding(backwardBy:) or something 
> similar, each taking a positive value of some kind to help avoid mistakes in 
> cases where the stride size is computed rather than constant, this would make 
> it more explicit at least.

I can’t imagine any scenario in which getting the step's sign wrong wouldn’t 
just be a typo. Why not just assign it the correct sign during the init 
function?
(0 ... 6).striding(by: 2) // [0, 2, 4, 6], end > start, so stride = by
(6 ... 0).striding(by: 2) // [6, 4, 2, 0], start > end, so stride = -by

(OTOH, I don’t understand why 6…0 is currently a crash, rather than the, IMHO, 
obviously intended sequence of “6,5,4,3,2,1,0”, so maybe I’m not the best 
person to ask)

- Dave Sweeris___
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

[Dave via swift-evolution]

> On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution 
>  wrote:
> 
> While I’m in favour of the basic idea I think the operator selection is too 
> complex, and I’m not sure about the need for negative strides. Really all I 
> want are the following:
> 
>   (0 ... 6).striding(by: 2)   // [0, 2, 4, 6] x from 0 to 6
>   (0 ..< 6).striding(by: 2)   // [0, 2, 4]x from 0 while 
> <6
>   (6 ... 0).striding(by: 2)   // [6, 4, 2, 0] x from 6 to 0
>   (6 ..> 0).striding(by: 2)   // [6, 4, 2]x from 6 while 
> >0
> 
> Everything else should be coverable either by flipping the order, or using 
> .reverse(). The main advantage is that there’s only one new operator to 
> clarify the 6 ..> 0 case, though you could always just reuse the existing 
> operator if you just interpret it as “x from 6 to, but not including, 0"

`.reverse()` returns an array, though, not a StrideTo<>, which means it’ll get 
in an infinite loop on infinite sequences. This works fine:
for i in stride(from: 0.0, to: Double.infinity, by: M_PI) {
if someTestInvolving(i) { break }
...
}

But this never even starts executing the loop because of the infinite loop 
inside `.reverse()`:
for i in stride(from: -Double.infinity, to: 0.0, by: M_PI).reverse() {
if someTestInvolving(i) { break }
...
}

- Dave Sweeris___
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 via swift-evolution]

> On Mar 30, 2016, at 12:26 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I didn't seem to ever need division. See attached playground (which
> borrows shamelessly from existing code and Erica's proposal, and which
> is written in Swift 2.2 because that's what I had handy).

Appending the following code to the playground reveals a bug/glitch:
import Darwin
let start = pow(2.0, 54)
let end = nextafter(start, Double.infinity)
let containsRepeatedValues = Array((start..

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Dave via swift-evolution]

Is it reasonable to think that the hypothetical type promotion system that 
Chris Lattner was alluding to *might* result in function signatures that are 
subtly different than what you’re proposing? If so, I’d be very hesitant to 
introduce them into the standard library. Perhaps there could be a 
“PossiblySketchyInSwift4MathStuff” package, once the package manager is ready?

- Dave Sweeris

> On Mar 30, 2016, at 6:10 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Would a valid stop-gap be to define operators for some of the common cases?
> 
> For example:
> 
> func * (lhs:Double, rhs:Int)->Double
> 
> Are there issues with this approach that I am unaware of?  It seems like the 
> desired cast (and the resulting effect) is obvious there, and you don’t get 
> surprising casts elsewhere.
> 
> Basically, the rule (as thought of by the programmer) would be in math which 
> mixes Ints & Doubles, the Int is treated as a double.  You could make a 
> similar rule for Int + CGFloat.
> 
> For math on mixed types, the result IMHO should follow this scale of 
> promotion (with the parameter farthest left on the scale also being the 
> result type):
> 
> CGFloat <- Double <- Float <- Int
> 
> I put CGFloat as the highest because in real-world code you often multiply a 
> CGFloat by a constant Double such as M_PI.  I can’t think of many cases where 
> you have a CGFloat and want anything but a CGFloat in return.
> 
> Thanks,
> Jon
> ___
> 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] Implicit Type Conversion For Numerics Where Possible.

[Dave via swift-evolution]

> On Mar 30, 2016, at 12:57 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Thank you, Robert & Haravikk
> Please allow me to respond in-line hereunder, thanks.
> Ted.
>> On 30.03.2016, at 16:15, Haravikk > > wrote:
>> 
>> I’m in favour of implicit conversion for integers where no data can be lost 
>> (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar thread a 
>> little while ago but can’t find it; there’s something being done with 
>> numbers so this may be partly in the works.
>> 
>> I definitely think that implicit conversion for floating point should be 
>> avoided, as it can’t be guaranteed
> Why?  and   What cannot be guaranteed? 


These all fail with a runtime error ("Playground execution aborted: Execution 
was interrupted, reason: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, 
subcode=0x0)”, if you’re curious):
Int(Double.infinity)
Int(Double.NaN)
Int(Double.quietNaN)

And this loop runs for 1024 iterations before finding just one instance where 
the conversion from Int to Double and back to Int actually gives the right 
answer:
var i = UInt(Int.max) + 1
var remainder = UInt()
repeat {
i -= 1
let DoubleI = UInt(Double(i))
remainder = DoubleI > i ? DoubleI - i : i - DoubleI
} while remainder != 0

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

Re: [swift-evolution] SetAlgebra naming update

[Dave via swift-evolution]

> On Mar 25, 2016, at 4:45 PM, Dave Abrahams  wrote:
> 
> on Fri Mar 25 2016, davesweeris-AT-mac.com wrote:
> 
>> Can we rename `subtract` to `complement`, since that’s the correct
>> term? At least, I’m assuming that’s what `subtract` means… if not, I’m
>> confused.
>> https://en.wikipedia.org/wiki/Set_(mathematics)#Complements
> 
> It's not just “complement,” because that means inverting set membership
> of everything in a finite domain.  It would have to be “relative
> complement.”  But “relative complement” lacks the directional
> implication that plagues terms like “difference,” but not “subtracting.”

Fair points… I accidentally left off the argument label. May I amend my 
suggestion to "rename `subtract(:)` to `complement(relativeTo:)`”? It just 
seems to me that if we’re going to claim we’re implementing something, we 
should adopt as much of its “standard" syntax and terminology as possible. It 
makes Swift easier to use for those coming from other disciplines, IMHO.

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

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Dave via swift-evolution]

I’m pretty sure I only use them with `@IBOutlet` vars.

One of the alternatives list is: 
• Remove IUOs completely. Untenable due to the prevalence of deferred 
initialization and unannotated Objective-C API in today's Swift ecosystem.

What about leaving IUOs in the compiler, but disallowing them unless the code 
is marked @objc (and treating them as `T?` in code that isn’t)? The stated 
motivation is "This proposal seeks to limit the adoption of IUOs to places 
where they are actually required, and put the Swift language on the path to 
removing implicitly unwrapped optionals from the system entirely when other 
technologies render them unnecessary.”… If they’re only intended to be used 
with C/Obj-C code, seems like that’s something that’d be possible for the 
compiler to enforce.

Having typed this all out, I’m starting to suspect it might be more complicated 
than what we have now… Hmm… I’ll hit send anyway, in case I’m wrong.

- Dave Sweeris

> On Mar 25, 2016, at 3:10 PM, Joseph Lord via swift-evolution 
>  wrote:
> 
> On 25/03/2016 15:24, Chris Lattner via swift-evolution wrote:
>> Hello Swift community,
>> 
>> The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs 
>> through March 30th. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
>> 
> 
> As I don't use IUO optionals I'm really fairly neutral on the proposal. I 
> just wanted to mention with the powerful tools we have for dealing with 
> optionals (optional, chaining, nil-coalescing, map, flatmap, guard, and let - 
> thanks Chris and team) it really would be quite feasible to do away with IUOs 
> completely. I don't think the community is ready for that yet so I'm not 
> proposing that course of action at this time but such a proposal wouldn't get 
> a universally hostile response.
> 
> Even force unwrap is something that I only do test code since flatmap was 
> added to the Standard Library (I used to have my own implementation of 
> flatmap with a force unwrap after a filter which was the only production use 
> I've put force unwrap to).
> 
> Joseph
> ___
> 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

[Dave via swift-evolution]

Huge +1 from me, but a character can't be valid for both function/variable 
names and operators because it'd break something in the compiler. Or at least I 
think that’s what I remember reading here.

That doesn’t strictly rule out custom keywords, but those are probably part of 
the AFAIK-still-out-of-scope macro discussion.

- Dave Sweeris

> On Mar 24, 2016, at 9:24 AM, David Knothe via swift-evolution 
>  wrote:
> 
> Well I would love to be able to create and use my own keywords / alphanumeric 
> operators.
> Depending on the type of code you are writing, these may be more or less 
> helpful. The same is true for the 'step' keyword - maybe most people won't 
> ever use it - but I think there should certainly be a possiblity, be it a 
> concrete keyword built into the language or the possibility to create my own 
> ones.

___
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 via swift-evolution]

I don’t think you'd even need a new operator. This works with Ints (haven’t 
tried anything else):
extension Strideable {
func stride(by by: Self.Stride) -> (last: Self, by: Self.Stride) {
return (self, by)
}
}
func ..<  (first: T, rhs: (last: T, by: T.Stride)) -> 
StrideTo {
return first.stride(to: rhs.last, by: rhs.by)
}
func ...  (first: T, rhs: (last: T, by: T.Stride)) -> 
StrideThrough {
return first.stride(through: rhs.last, by: rhs.by)
}

Array(0..<10.stride(by: 2)) //[0, 2, 4, 6, 8]
Array(0...10.stride(by: 2)) //[0, 2, 4, 6, 8, 10]


> On Mar 24, 2016, at 3:40 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> If it's parentheses you want to avoid, you don't need a keyword to do that. 
> For example, I can make a stride operator `..+` in four lines like so:
> 
> ```
> infix operator ..+ { associativity left precedence 134 }
> func ..+ (left: Range, right: Element.Stride) 
> -> StrideTo {
> return left.startIndex.stride(to: left.endIndex, by: right)
> }
> 
> // example of usage:
> for i in 1..<10..+2 {
> print(i)
> }
> ```

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Dave via swift-evolution]

> On Mar 14, 2016, at 9:42 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> Although really, why not just use “file” instead of “internal” since it won’t 
> burn any keywords or cause any other conflicts as far as I know.
> 
> l8r
> Sean
IMHO, “file” is a reasonable variable name. Although if you’re talking about 
‘private(file)’ rather than just ‘file’, that might not be a problem.

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

Re: [swift-evolution] Simplifying Function Parameter List (when calling)

[Dave via swift-evolution]

> On Mar 14, 2016, at 4:34 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> (spawned from subject: "Make the first parameter in a function follow the 
> same rules as the others”)
> 
> Idea:  Eliminate commas from the parameter list when calling a function, 
> because they are not necessary. 
Commas may not be necessary from the parser’s point of view, but to me having a 
non-whitespace delimiter significantly aids readability.

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

Re: [swift-evolution] Add an ifPresent function to Optional

[Dave via swift-evolution]

> On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution 
>  wrote:
> 
> Optional.map returns an Optional.
> 
> Array.map returns an Array.
> Set.map returns an Array.
> .map returns an Array.
> 
> I can't say that it is not valid to think about an Optional as a tiny
> collection, but as implemented in Swift, .map() does objectively
> behave differently...
That behavior is, at least partially, because protocols don’t currently support 
this:
protocol CollectionType {
typealias T
func map(transform: T->U) -> Self // error: Cannot specialize 
non-generic type 'Self'
}
I *think* I remember reading on here somewhere that the intent is to change map 
and flatMap to return “Self" pretty much as soon as the language supports 
it. Someone from Apple would have to confirm that, though… my memory is quite 
hazy on the matter.

More to the point, in terms of what you could actual do with a variable, 
there’s no real difference between:
var foo: [Int] = []
and
var foo: Int? = nil
In both cases you have to check foo's “count” so to speak, before you can 
safely access its element(s), otherwise the most you can do is pass it along to 
some other code. If the language had the features to support it, Optional could 
literally be defined like this:
typealias Optional = Array
While the syntax of how we’d interact with Optionals might change, functionally 
speaking, I can’t think of any difference at all. Both provide storage for a 
variable # of elements (only slightly variable in Optional’s case, but variable 
none the less), both throw equally fatal errors if you try to access elements 
that don’t exist, and provide quick access to those that do exist. Furthermore, 
within the limitation of how many “elements” an Optional can store, it’s 
trivial to convert between the two types:
extension Array {
init(_ x: Element?) {
switch x {
case .None: self = []
case .Some(let value): self = [value]
}
}
}
extension Optional {
init(arrayLiteral elements: [Optional.Wrapped]) {
switch elements.count {
case 0: self = .None
case _: self = .Some(elements[0])
}
}
}

All this suggests, to me anyway, that at least in this regard, they’re the same 
“meta type”. What’s the harm in having the API reflect that?

- Dave Sweeris

P.S. Should we be having this conversation in a different thread? I’m *really* 
bad about going down every rabbit hole I can find, and I don’t want to upset 
the mailing list by dragging them along with me...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution