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

[Thorsten Seitz via swift-evolution]

Dijkstra is talking about intervals of natural numbers, i.e. indices.
Range is much more general than that, including floating point ranges, so 
Dijkstra's arguments do not apply here.

-Thorsten 

Am 06.04.2016 um 23:41 schrieb Brent Royal-Gordon via swift-evolution 
:

>> From a purely numerically aesthetic point of view, I'd much prefer ranges to 
>> be 
>> openable and closable at both ends. 
>> 
>> My primary use-case has been teaching math using playgrounds but I'm sure 
>> there are lots of other real-world situations more specific to common 
>> numerical
>> method tasks.
> 
> By coincidence, a Perl hacker I know commented on Twitter yesterday that he 
> thought 1-based arrays were the way to go in the 21st century. Somebody 
> replying to that suggestion linked to a note by Dijkstra that's relevant to 
> this conversation: 
> 
> 
> I'd suggest everyone in this discussion should read it—it's only about 700 
> words—but to summarize:
> 
>1. The semantic Swift refers to as `..<` is the most natural range 
> convention.
>2. Relatedly, zero-based indexing is the most natural indexing convention.
> 
> If we agree with Dijkstra's logic, then the only reason to support `>..` is 
> for ranges where start > end—that is, when we're constructing a reversed 
> range. But if we decide to support striding backwards by using a forward 
> range and a negative stride, then that covers the reverse use case. Thus, we 
> would need neither additional range operators, nor reversed ranges.
> 
> As for the `range.striding(by:)` vs `stride(over:by:)` question, my concerns 
> there are, to be honest, mainly aesthetic. The need for parentheses around 
> the range operator is more or less unavoidable, but I think they make the 
> construct very ugly. However, I also think that the `stride(over:by:)` syntax 
> (or, for that matter `stride(from:to:by:)`) look more constructor-y (they are 
> only *not* constructors now because of the overloading), and I think it opens 
> us up to parallel constructs like the `induce(from:while:by:)` function I've 
> been working on.
> 
> -- 
> 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

[Thorsten Seitz via swift-evolution]

> Am 06.04.2016 um 23:26 schrieb Stephen Canon via swift-evolution 
> :
> 
> 
>> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>>> on Wed Apr 06 2016, Erica Sadun  wrote:
>>> 
>>>   On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution
>>>wrote:
>>> 
>>>   on Wed Apr 06 2016, Xiaodi Wu  wrote:
>>> 
>>>   On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>>>wrote:
>>> 
>>>   You if you need to represent `<..` intervals in scientific computing,
>>>   that's a pretty compelling argument for supporting them.
>>> 
>>>   I'd like to be able to represent any of those as
>>>   Intervals-which-are-now-Ranges. It makes sense to do so 
>>> because
>>>   the
>>>   things I want to do with them, such as clamping and testing if
>>>   some
>>>   value is contained, are exactly what Intervals-now-Ranges
>>>   provide.
>>>   Looking around, it seems many other languages provide only 
>>> what
>>>   Swift
>>>   currently does, but Perl does provide `..`, `..^`, `^..`, and
>>>   `^..^`
>>>   (which, brought over to Swift, would be `...`, `..<`, `<..`, 
>>> and
>>>   `<.<`).
>>> 
>>>   Do we need fully-open ranges too?
>>> 
>>>   I haven't encountered a need for open ranges, but I would expect that
>>>   other applications in scientific computing could make use of them.
>>>   I rather like Pyry's suggestions below. 
>>> 
>>>   Below?
>>> 
>>> Logically in time below.
>> 
>> Oh! In my application, time flows downward.
>> 
>>> 
>>> I believe the following is a valid conversion of the Xiaodi Wu below into 
>>> the
>>> Dave A domain.
>>> 
>>>   On Apr 6, 2016, at 2:29 PM, Pyry Jahkola via swift-evolution
>>>wrote:
>>> 
>>>   I think a sensible specification would be that with a positive step size,
>>>   the count starts from the lower bound, and with a negative one, it starts
>>>   from the upper bound (inclusive or exclusive). Thus, the following 
>>> examples
>>>   should cover all the corner cases:
>>> 
>>>   (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]
>> 
>> These all look reasonable to me.
> 
> Agreed.

I agree as well. Makes sense.

-Thorsten 
___
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

[Thorsten Seitz via swift-evolution]

> Am 06.04.2016 um 23:03 schrieb Dave Abrahams via swift-evolution 
> :
> 
> 
>> on Wed Apr 06 2016, Erica Sadun  wrote:
>> 
>>On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>Guidance:
>> 
>>When using odd integer literals to produce an even number sequence,
>>prefer the `...` operator to the `..<` operator and change your ending
>>literal to an even number.
>> 
>>I don't think you can fix counterintuitive behavior with guidance. 
>> 
>>(1..<199).striding(by: -2) is the first way I'd reach for to express
>>197, 195, ..., 3, 1
>> 
>> Yes, but you can with warnings and fixits. 
>> 
>> * The compiler should issue a warning for any use of 
>> 
>> (n..> 
>> with a fixit of "replace (n..> whether n or m is known at compile time 
>> 
>> * If v cannot be known at compile time, I think the compiler should
>> always prefer ... to ..<.
>> 
>> * The compiler should not allow
>> 
>> (n..> 
>> where v is known at compile time to be a negative constant. There should 
>> also be a runtime precondition that raises a fatal error should a negative 
>> v be used with a half-open interval.
> 
> You can lessen the impact of any design choice by adding warnings and
> fixits, but I'm pretty sure it's better to make a choice that doesn't
> require them.

Absolutely! Having to add warnings and fixits just demonstrates that the design 
is confusing. 

-Thorsten
___
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

[David Hart via swift-evolution]

I agree with Sean, I ready use guard and don't see much use in a StdLib or 
operator alternative.

Sent from my iPad

> On 06 Apr 2016, at 17:00, Sean Heber via swift-evolution 
>  wrote:
> 
> Interesting, but I’m unsure if all of it is significantly better than just 
> using the guard that is effectively inside of the operator/func that is being 
> proposed:
> 
> guard let value = Int("NotANumber") else { throw 
> InitializerError.invalidString }
> 
> It is only a couple of characters longer and already works (it’s what I use 
> currently). If guard allowed for a special single-expression variation so 
> that you didn’t need to specify the ugly braces or something, it’d look 
> prettier and be nice for a lot of other situations, too:
> 
> guard let value = Int("NotANumber") else: throw InitializerError.invalidString
> guard someVal < 10 else: return false
> guard mustBeTrue() else: return
> // etc
> 
> Not to derail this, but I sort of want this ability anywhere as a shorthand 
> for a single-expression block.
> 
> if something < 42: doThing()
> for a in list: print(a)
> 
> But I imagine that’ll never fly. :P
> 
> l8r
> Sean
> 
> 
> 
>> On Apr 6, 2016, at 9:46 AM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Pyry Jahkola and I have been plugging away on the following which is 
>> preliminary enough not to qualify as an actual draft. He prefers the Mike 
>> Ash approach. I prefer the operator approach. So we have not actually 
>> settled on which one we would actually propose despite how I've written this 
>> up.
>> 
>> I'm putting this out there to try to gain a consensus on:
>> 
>> * Would this be a viable proposal?
>> * If so, which of the options would work best within Swift's design and 
>> philosophy 
>> 
>> Thanks for your feedback.
>> 
>> -- Erica
>> Introduction
>> 
>> Swift's try? keyword transforms error-throwing operations into optional 
>> values. We propose adding an error-throwing nil-coalescing operator to the 
>> Swift standard library. This operator will coerce optional results into 
>> Swift's error-handling system. 
>> 
>> This proposal was discussed on the Swift Evolution list in the name thread.
>> 
>> Motivation
>> 
>> Any decision to expand Swift's set of standard operators should be taken 
>> thoughtfully and judiciously. Moving unaudited or deliberately 
>> non-error-handling nil-returning methods and failable initializers into 
>> Swift's error system should be a common enough use case to justify 
>> introducing a new operator.
>> 
>> Detail Design
>> 
>> We propose adding a new operator that works along the following lines:
>> 
>> infix operator ??? {}
>> 
>> func ???(lhs: T?, @autoclosure error: () -> ErrorType) throws -> T {
>>guard case let value? = lhs else { throw error() }
>>return value
>> }
>> 
>> The use-case would look like this:
>> 
>> do {
>>let error = Error(reason: "Invalid string passed to Integer initializer")
>>let value = try Int("NotANumber") ??? InitializerError.invalidString
>>print("Value", value)
>> } catch { print(error) }
>> 
>> Note
>> 
>> SE-0047 (warn unused result by default) and SE-0049 (move autoclosure) both 
>> affect many of the snippets in this proposal
>> 
>> Disadvantages to this approach:
>> 
>>• It consumes a new operator, which developers must be trained to use
>>• Unlike many other operators and specifically ??, this cannot be 
>> chained. There's no equivalent to a ?? b ?? c ?? dor a ?? (b ?? (c ?? d)).
>> Alternatives Considered
>> 
>> Extending Optional
>> 
>> The MikeAsh approach extends Optional to add an orThrow(ErrorType) method
>> 
>> extension Optional {
>>func orThrow(@autoclosure error: () -> ErrorType) throws -> Wrapped {
>>guard case let value? = self else { throw error() }
>>return value
>>}
>> }
>> 
>> Usage looks like this:
>> 
>> do {
>>let value = try Int("NotANumber")
>>.orThrow(InitializerError.invalidString)
>>print("Value", value)
>> } catch { print(error) }
>> 
>> An alternative version of this call looks like this: optionalValue.or(throw: 
>> error). I am not a fan of using a verb as a first statement label.
>> 
>> Disadvantages:
>> 
>>• Wordier than the operator, verging on claustrophobic, even using 
>> Swift's newline dot continuation.
>>• Reading the code can be confusing. This requires chaining rather than 
>> separating error throwing into a clear separate component. 
>> Advantages:
>> 
>>• No new operator, which maintains Swift operator parsimony and avoids 
>> the introduction and training issues associated with new operators.
>>• Implicit Optional promotion cannot take place. You avoid mistaken usage 
>> like nonOptional ??? error and nonOptional ?? raise(error).
>>• As a StdLib method, autocompletion support is baked in.
>> Introducing a StdLib implementation of raise(ErrorType)
>> 
>> Swift could introduce a raise(ErrorType) -> T global function:
>> 
>> func raise(error: ErrorType) throws -> T { throw error }
>>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[David Hart via swift-evolution]

There's something I find very confusing with this proposal, and it's how Self 
is already used in protocol definitions to represent the STATIC type of the 
type that conforms to the protocol. I think people will be potentially very 
confused by how Self represents different types in different contexts:

protocol Copyable {
func copy() -> Self
}

class Animal : Copyable {
init() {}
func copy() -> Animal {
return Self.init()
}
}

class Cat : Animal {}

In the previous sample, wouldn't it be confusing to people if Self in the 
protocol means Animal in the Animal type, but Self in the Animal type may mean 
Cat?

Sent from my iPad
> On 06 Apr 2016, at 18:51, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 5, 2016, at 4:04 PM, Joe Groff  wrote:
>>> 
>>> 
>>> On Apr 5, 2016, at 3:02 PM, Erica Sadun  wrote:
>>> 
>>> As the discussion seems to be quieting down, I've tried to summarize the 
>>> on-list discussion and distill it into a preliminary proposal draft. Please 
>>> let me know if this covers what you think it should or if I've entirely 
>>> missed the mark. (It wouldn't be the first time.)
>>> 
>>> Regards,  -- Erica
> 
> 
> Pull Request 248: https://github.com/apple/swift-evolution/pull/248
> 
> Within a class scope, Self means "the dynamic class of self". This proposal 
> extends that courtesy to value types, where dynamic Self will match a 
> construct's static type, and to the bodies of class members, where it may 
> not. It also introduces a static variation, #Self that expands to static type 
> of the code it appears within.
> 
> This proposal was discussed on the Swift Evolution list in the [Pitch] Adding 
> a Self type name shortcut for static member access thread.
> 
> Thanks, -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] divisible-by operator

[Félix Cloutier via swift-evolution]

This is the kind of thing that I'd let live in a library and consider importing 
into the standard if a lot of people use it.

Félix

> Le 6 avr. 2016 à 09:13:41, Milos Rankovic via swift-evolution 
>  a écrit :
> 
> Checking for divisibility is very common:
> 
> 21 % 3 == 0 // true
> 
> In fact, this is such a common use of the `%` operator that the `== 0` side 
> of the expression seems distracting in this use case. For quite a while now, 
> I’ve been using a custom operator for this, which is steadily growing on me:
> 
> 21 %== 3 // true
> 
> … which also allows me to overload it for sequences:
> 
> 21 %== [7, 3] // true
> 
> (If I’m inadvertently misusing this mailing list to share such a minor idea, 
> please tell me off so that I can learn not to do it again!)
> 
> 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] Feature proposal: Range operator with step

[Thorsten Seitz via swift-evolution]

> Am 06.04.2016 um 22:17 schrieb Xiaodi Wu via swift-evolution 
> :
> 
>> On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams  wrote:
>> 
>>> on Wed Apr 06 2016, Erica Sadun  wrote:
>>> 
>>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution
>>> wrote:
>>>(0..<199).striding(by: -2)
>>> 
>>>are even or odd.
>>> 
>>> (0..<199).striding(by: -2): 0..<199 == 0...198 Even
>>> (1..<199).striding(by: -2): 1..<199 == 1...198 Even
>> 
>> I understand the logic that got you there, but I find it incredibly
>> counter-intuitive that striding by 2s over a range with odd endpoints
>> should produce even numbers... I can't imagine any way I'd be convinced
>> that was a good idea.
>> 
>>> (0..<198).striding(by: -2): 1..<198 == 0...197 Odd
>>> (1..<198).striding(by: -2): 1..<198 == 1...197 Odd
> 
> One other aspect of the counterintuitiveness is that
> `(a.. essentially reversing the sequence given by `(a.. That would not be the case with the logic presented here. I worry that
> there is no obviously correct interpretation of `(a.. -c)` and wonder if any conclusion arrived at would necessarily be more
> confusing that `stride(from:to:by:)`.

Yep, that's my impression, too.

-Thorsten 
___
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

[Thorsten Seitz via swift-evolution]

> Am 06.04.2016 um 20:26 schrieb Erica Sadun via swift-evolution 
> :
> 
>>> On Apr 6, 2016, at 12:23 PM, Stephen Canon via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution 
  wrote:
 
 On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution 
  wrote:
 
 One question that I *do* think we should answer, is whether the elements
 of
 
(0..<199).striding(by: -2)
 
 are even or odd.
>>> 
>>> Odd.  I don’t believe that many real use cases care, but odd is more 
>>> efficient from a performance perspective.  Needs to be documented clearly, 
>>> however.
>> 
>> Sorry, I was thinking of (0…199).striding(by: -2).
>> 
>> For the (0..<199) case, Erica’s assessment seems about right, though it 
>> isn’t at all obvious how it generalizes to floating point strides.
> 
> (l.. cannot be a starting value.

Why?
The starting value could quite naturally be s = l + k*dX for the largest value 
of k in the natural numbers for which s < h, wouldn't it?

-Thorsten 
___
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

[John McCall via swift-evolution]

> On Apr 6, 2016, at 9:21 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
>>> Interesting, but I’m unsure if all of it is significantly better than just 
>>> using the guard that is effectively inside of the operator/func that is 
>>> being proposed:
>>> 
>>> guard let value = Int("NotANumber") else { throw 
>>> InitializerError.invalidString }
>>> 
>> 
>> That is a pretty damn compelling argument.
> 
> For some cases, yes. For others…
> 
>   myInt = Int("NotANumber") ?? throw InitializerError.invalidString
> 
> On the other hand, all we really need is a generalized "noneMap" function 
> marked as rethrowing, which can serve multiple purposes.
> 
>   myOtherInt = Int("NotANumber").noneMap(arc4random)
>   myInt = try Int("NotANumber").noneMap { throw 
> InitializerError.invalidString }
> 
> On the gripping hand: I think this is only a problem because `throw` is a 
> statement, not an expression. Could it be changed to be an expression with an 
> unspecified return type? I believe that would allow you to simply drop it 
> into the right side of a ?? operator, and anywhere else you might want it 
> (boolean operators, for instance).

For what it's worth, this is how it was originally designed.  Reducing it to a 
statement was a simplification to gain consensus.

John.
___
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

[Brent Royal-Gordon via swift-evolution]

> I know you're not proposing that feature right now, but want to understand 
> how you expect it to work.  It looks to me like this starts to enter design 
> by contract territory.  Would the predicate behave as if it was part of a 
> precondition?

I suppose I imagine it as equivalent to a precondition() placed at the call 
site, rather than inside the function. If the compiler can prove that the 
precondition will be violated, it can refuse to compile the call. But I haven't 
thought deeply about it, so I don't really know for sure.

-- 
Brent Royal-Gordon
Architechies

___
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

[Trent Nadeau via swift-evolution]

Another +1 to `where` at the end.

On Wed, Apr 6, 2016 at 10:33 PM, Matt Whiteside via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 to moving the `where` clause after the function signature.
>
> -Matt
>
> > On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> If you've ever gotten to the point where you have a sufficiently
> generic interface to a thing and you need to constrain it, possibly in an
> extension, maybe for a generic free function or operator, you know what a
> pain the syntax can be for these kinds of operations.  For example, the
> Swift book implements this example to motivate where clauses
> >>
> >> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element>
> (lhs: T, _ rhs: U) -> Bool
> >>
> >> This is noisy and uncomfortable to my eyes, and almost impossible to
> align correctly.  Per a short discussion on Twitter with Joe Groff and
> Erica Sadun, I'd like so see what the community feels about moving the
> where clause out of the angle brackets.  So that example becomes
> >>
> >> func anyCommonElements 
> >> where T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element
> >> (lhs: T, _ rhs: U) -> Bool
> >>
> >> Or, if you're feeling ambitious, even
> >>
> >> func anyCommonElements 
> >> where T : SequenceType, U : SequenceType,
> >> T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element
> >> (lhs: T, _ rhs: U) -> Bool
> >>
> >> Thoughts?
> >
> > I think this is a good idea, though I would put the `where` clause after
> the function signature:
> >
> > func foo(x: T, y: U) -> Result
> >where T.Foo == U.Bar /*, etc. */
> > {
> > }
> >
> > As others noted, it's also appealing to do this for type declarations
> too:
> >
> > struct Foo
> >where T.Foo == U.Bar
> > {
> > }
> >
> > and that gives a consistent feeling with extensions and protocol
> declarations.
> >
> > -Joe
> > ___
> > 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
>



-- 
Trent Nadeau
___
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]

+1 to moving the `where` clause after the function signature.

-Matt

> On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>>  wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.  For example, the Swift book 
>> implements this example to motivate where clauses
>> 
>> func anyCommonElements > T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> This is noisy and uncomfortable to my eyes, and almost impossible to align 
>> correctly.  Per a short discussion on Twitter with Joe Groff and Erica 
>> Sadun, I'd like so see what the community feels about moving the where 
>> clause out of the angle brackets.  So that example becomes
>> 
>> func anyCommonElements 
>> where T.Generator.Element: Equatable, T.Generator.Element == 
>> U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> Thoughts?
> 
> I think this is a good idea, though I would put the `where` clause after the 
> function signature:
> 
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
> 
> As others noted, it's also appealing to do this for type declarations too:
> 
> struct Foo
>where T.Foo == U.Bar
> {
> }
> 
> and that gives a consistent feeling with extensions and protocol declarations.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Kevin Lundberg via swift-evolution]

On 4/6/2016 1:22 PM, Russ Bishop wrote:
> The original intent was to be available on platforms that have an
> Objective-C runtime (Darwin only at the moment, I guess in theory
> Windows if someone were determined enough).
>
>
> You bring up a good point; there is nothing in the protocol that
> absolutely requires Objective-C, only that it requires AnyObject be
> the root object type. 
>
> However in some hypothetical world where we support importing C++
> types, Rust types, or JavaScript (only half trolling) types it would
> be nice for this protocol to have something tying it to the idea that
> we are bridging to the Objective-C/corelibs-foundation runtime
> specifically.
>
>
> Russ

Good point. I was going to suggest breaking out the protocol into a
general swift version and have an objective-c specific one refine it,
but in the case where bridging to other languages happens, those other
language specific bridging protocols wouldn't be able to refine the
generic base protocol for types that want to bridge more than one
language. I formally retract my concern :)
___
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

[Matthew Judge via swift-evolution]

> On Apr 6, 2016, at 17:00, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 06 2016, Erica Sadun  wrote:
> 
>>> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu  wrote:
>>> Prohibiting StrideTo with floating-point ranges altogether would be
>>> distressing. IMO, it's plenty distressing that backwards
>>> floating-point StrideTo as it currently exists might go away.
>> 
>> I wouldn't suggest doing so. I'm just saying that for a half-open interval, 
>> there is no max value
>> so it makes no sense mathematically to have a first value and a
>> negative step.
> 
> I don't agree.  It seems to me that striding downwards over a half-open
> range r should always begin with r.upperBound - s (modulo any necessary
> adjustments to avoid FP error), where -s is the stride amount.  Why is
> that mathematical nonsense?
> 
This doesn't seem intuitive to me at all.

I can think of three interpretations of '(lBound.. Another point to consider: striding is also a sensible operation over
> collections, and some ranges are collections.  The stride semantics must
> coincide in those cases.  I expect that constraint narrows down the
> reasonable semantic choices considerably.
> 
>> You're not so restricted with:
>> 
>> * positive steps
>> * closed intervals
>> 
>> -- E
>> 
>> ___
>> 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
___
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

[Yuta Koshizawa via swift-evolution]

I agree with this and I like the operator approach.

Besides the proposed infix `???`, I also want the postfix one which
throws a `NilError` (something like `struct NilError: ErrorType {}`).
It is useful to handle multiple `nil`s at once when we are not
interested in the kind of the error.

```
// Decodes a JSON with SwiftyJSON
do {
  let person: Person = try Person(
firstName: json["firstName"].string???,
lastName: json["lastName"].string???,
age: json["age"].int???
  )
} catch _ {
  // Error handling
}
```

Considering the postfix one, the operator approach for the infix one
is consistent.

One more thing; I think `???` is too long. Instead, I propose `|?`.
For `foo: Foo?`, `try foo|?` can be read like `Foo` or `nil`. It
separates (`|`) nil (`?`) from the value and return `Foo`. I think it
makes sense.

-- Yuta

2016-04-06 23:46 GMT+09:00 Erica Sadun via swift-evolution
:
> Pyry Jahkola and I have been plugging away on the following which is
> preliminary enough not to qualify as an actual draft. He prefers the Mike
> Ash approach. I prefer the operator approach. So we have not actually
> settled on which one we would actually propose despite how I've written this
> up.
>
> I'm putting this out there to try to gain a consensus on:
>
> * Would this be a viable proposal?
> * If so, which of the options would work best within Swift's design and
> philosophy
>
> Thanks for your feedback.
>
> -- Erica
>
> Introduction
>
> Swift's try? keyword transforms error-throwing operations into optional
> values. We propose adding an error-throwing nil-coalescing operator to the
> Swift standard library. This operator will coerce optional results into
> Swift's error-handling system.
>
> This proposal was discussed on the Swift Evolution list in the name thread.
>
> Motivation
>
> Any decision to expand Swift's set of standard operators should be taken
> thoughtfully and judiciously. Moving unaudited or deliberately
> non-error-handling nil-returning methods and failable initializers into
> Swift's error system should be a common enough use case to justify
> introducing a new operator.
>
> Detail Design
>
> We propose adding a new operator that works along the following lines:
>
> infix operator ??? {}
>
> func ???(lhs: T?, @autoclosure error: () -> ErrorType) throws -> T {
> guard case let value? = lhs else { throw error() }
> return value
> }
>
> The use-case would look like this:
>
> do {
> let error = Error(reason: "Invalid string passed to Integer
> initializer")
> let value = try Int("NotANumber") ??? InitializerError.invalidString
> print("Value", value)
> } catch { print(error) }
>
> Note
>
> SE-0047 (warn unused result by default) and SE-0049 (move autoclosure) both
> affect many of the snippets in this proposal
>
> Disadvantages to this approach:
>
> It consumes a new operator, which developers must be trained to use
> Unlike many other operators and specifically ??, this cannot be chained.
> There's no equivalent to a ?? b ?? c ?? dor a ?? (b ?? (c ?? d)).
>
> Alternatives Considered
>
> Extending Optional
>
> The MikeAsh approach extends Optional to add an orThrow(ErrorType) method
>
> extension Optional {
> func orThrow(@autoclosure error: () -> ErrorType) throws -> Wrapped {
> guard case let value? = self else { throw error() }
> return value
> }
> }
>
> Usage looks like this:
>
> do {
> let value = try Int("NotANumber")
> .orThrow(InitializerError.invalidString)
> print("Value", value)
> } catch { print(error) }
>
> An alternative version of this call looks like this: optionalValue.or(throw:
> error). I am not a fan of using a verb as a first statement label.
>
> Disadvantages:
>
> Wordier than the operator, verging on claustrophobic, even using Swift's
> newline dot continuation.
> Reading the code can be confusing. This requires chaining rather than
> separating error throwing into a clear separate component.
>
> Advantages:
>
> No new operator, which maintains Swift operator parsimony and avoids the
> introduction and training issues associated with new operators.
> Implicit Optional promotion cannot take place. You avoid mistaken usage like
> nonOptional ??? error and nonOptional ?? raise(error).
> As a StdLib method, autocompletion support is baked in.
>
> Introducing a StdLib implementation of raise(ErrorType)
>
> Swift could introduce a raise(ErrorType) -> T global function:
>
> func raise(error: ErrorType) throws -> T { throw error }
>
> do {
> let value = try Int("NotANumber") ??
> raise(InitializerError.invalidString)
> print("Value", value)
> } catch { print(error) }
>
> This is less than ideal:
>
> This approach is similar to using && as an if-true condition where an
> operator is abused for its side-effects.
> It is wordier than the operator approach.
> The error raising function promises to return a type but never will, which
> seems hackish.
>
> Overriding ??
>
> We also considered overriding ?? to accept an err

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

[Howard Lovatt via swift-evolution]

I like the idea that Array gains `strinding(by:)` but would also like Range
to be like an array, same interface, and hence also gain `strinding(by:)`,
hence:

calendar[(startDate ..< endDate).striding(by: .Day)]


  -- Howard.

On 7 April 2016 at 10:53, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Apr 06 2016, Brent Royal-Gordon  wrote:
>
> >> I (am familiar with and) agree with Dijkstra's logic, but not with your
> >> conclusion about it.  The fact that one representation is more natural
> >> for most common computing tasks doesn't mean it's not worth supporting
> >> the other representations.
> >
> > I'm not saying that Dijkstra proves that we don't need any other range
> > operators. Rather, I'm saying that he demonstrates why supporting
> > `..<` but not `<..` is not arbitrary or capricious. Dijkstra's
> > argument *permits* us to privilege `..<` as uniquely important, but
> > doesn't *force* us to do so.
>
> I agree.  And I still think it's uniquely important ;-).
>
> > To another person just now, you said:
> >
> >> He was talking about ranges of integer indices, though, and even
> >> more-specifically about how to address arrays.  Range is a more
> >> general concept that applies to much more than indices.  Once you
> >> involve floating point (and rationals, and patterns for matching,
> >> e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.
> >
> > I actually think he was talking a little more broadly than
> > that—essentially, he was discussing ordered, discrete types. In
> > principle, the same argument applies to UnicodeScalars,
>
> Yes, but I don't know if he had such types.
>
> > but not to floating-point numbers (unless you use treat floats as a
> > discrete type using `nextafter` as the `successor()` operation, which
> > is coherent but not very useful in practice). Having said that, I *do*
> > think that `...` is in practice quite useful for many types. I'm less
> > certain that `<..` or `<.<` are.
> >
> > * * *
> >
> > By the way, another reason to have `stride` as a free function is that
> > I think some types need a "strider", an instance which performs the
> > striding.
> >
> > That was the conclusion I came to when I started experimenting with
> > striding over NSDates a week or two ago. The best design I could come
> > up with looked like this:
> >
> >   calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)
>
> > The `start` and `end` parameters could be grouped together into a
> > single parameter to match `stride(over:by:)`, but you can't put the
> > calendar or the unit into the stride—without them, there is no
> > coherent way to calculate the distance between two dates.
> >
> > So if some types need a strider, and will need to have the method
> > structured as `strider.stride(something:by:)`, it seems like the free
> > function version for types which *don't* need a strider ought to be
> > `stride(something:by:)`. The `something.striding(by:)` design can't be
> > easily adapted to this situation.
>
>   calendar[startDate..
> ?
>
> --
> 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

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

[Dave Abrahams via swift-evolution]

on Wed Apr 06 2016, Brent Royal-Gordon  wrote:

>> I (am familiar with and) agree with Dijkstra's logic, but not with your
>> conclusion about it.  The fact that one representation is more natural
>> for most common computing tasks doesn't mean it's not worth supporting
>> the other representations.
>
> I'm not saying that Dijkstra proves that we don't need any other range
> operators. Rather, I'm saying that he demonstrates why supporting
> `..<` but not `<..` is not arbitrary or capricious. Dijkstra's
> argument *permits* us to privilege `..<` as uniquely important, but
> doesn't *force* us to do so.

I agree.  And I still think it's uniquely important ;-).

> To another person just now, you said:
>
>> He was talking about ranges of integer indices, though, and even
>> more-specifically about how to address arrays.  Range is a more
>> general concept that applies to much more than indices.  Once you
>> involve floating point (and rationals, and patterns for matching,
>> e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.
>
> I actually think he was talking a little more broadly than
> that—essentially, he was discussing ordered, discrete types. In
> principle, the same argument applies to UnicodeScalars, 

Yes, but I don't know if he had such types.

> but not to floating-point numbers (unless you use treat floats as a
> discrete type using `nextafter` as the `successor()` operation, which
> is coherent but not very useful in practice). Having said that, I *do*
> think that `...` is in practice quite useful for many types. I'm less
> certain that `<..` or `<.<` are.
>
> * * *
>
> By the way, another reason to have `stride` as a free function is that
> I think some types need a "strider", an instance which performs the
> striding.
>
> That was the conclusion I came to when I started experimenting with
> striding over NSDates a week or two ago. The best design I could come
> up with looked like this:
>
>   calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)

> The `start` and `end` parameters could be grouped together into a
> single parameter to match `stride(over:by:)`, but you can't put the
> calendar or the unit into the stride—without them, there is no
> coherent way to calculate the distance between two dates.
>
> So if some types need a strider, and will need to have the method
> structured as `strider.stride(something:by:)`, it seems like the free
> function version for types which *don't* need a strider ought to be
> `stride(something:by:)`. The `something.striding(by:)` design can't be
> easily adapted to this situation.

  calendar[startDate..https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

I like the idea, I find the beginning of a declaration too cluttered and it
obscures the main purpose. Like Brent I am wary of the design by contract
(DBC) bit, `lhs <= rhs`. DBC is probably for a separate discussion, but
moving the where clause would probably help.

  -- Howard.

On 7 April 2016 at 10:36, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> >> I would actually move them as far as after everything else, and right
> before the definition body. For the above function that would mean:
> >>
> >> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> >>where T : SequenceType,
> >>  U : SequenceType,
> >>  T.Generator.Element: Equatable,
> >>  T.Generator.Element == U.Generator.Element
> >> {
> >>...
> >> }
> >>
> >> That would make the definition look closer to what the call site looks
> like.
> >>
> >> The same would work for generic types  too:
> >>
> >> public struct Dictionary
> >>where Key : Hashable
> >> {
> >>   ...
> >> }
> >
> > Another nice thing about this style is that, in principle, I think it
> could be extended to specify requirements on non-type parameter values.
> >
> >func ..< (lhs: Element, rhs: Element) ->
> Range
> >where Element: Comparable, lhs <= rhs {
> >…
> >}
> >
> > I'm not saying we must or even should include that feature, merely that
> it gives us a nice syntactic slot to use if we choose to do so later.
>
> I know you're not proposing that feature right now, but want to understand
> how you expect it to work.  It looks to me like this starts to enter design
> by contract territory.  Would the predicate behave as if it was part of a
> precondition?
>
> > --
> > 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
>
___
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

[Matthew Johnson via swift-evolution]

Sent from my iPad

On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> I would actually move them as far as after everything else, and right before 
>> the definition body. For the above function that would mean:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>>where T : SequenceType,
>>  U : SequenceType,
>>  T.Generator.Element: Equatable,
>>  T.Generator.Element == U.Generator.Element
>> {
>>...
>> }
>> 
>> That would make the definition look closer to what the call site looks like.
>> 
>> The same would work for generic types  too:
>> 
>> public struct Dictionary
>>where Key : Hashable
>> {
>>   ...
>> }
> 
> Another nice thing about this style is that, in principle, I think it could 
> be extended to specify requirements on non-type parameter values.
> 
>func ..< (lhs: Element, rhs: Element) -> 
> Range
>where Element: Comparable, lhs <= rhs {
>…
>}
> 
> I'm not saying we must or even should include that feature, merely that it 
> gives us a nice syntactic slot to use if we choose to do so later.

I know you're not proposing that feature right now, but want to understand how 
you expect it to work.  It looks to me like this starts to enter design by 
contract territory.  Would the predicate behave as if it was part of a 
precondition?

> -- 
> 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Ross O'Brien via swift-evolution]

I'm hoping this extends to type values.

struct StructWithClosure
{
   let closure : (lhs: Element, rhs:Element) -> Range where
Element : Incrementable, Comparable
}

or for that matter, protocol values:

struct StructWithIntCollectionType
{
let collection : C where C : CollectionType, C.Element == Int
}


On Thu, Apr 7, 2016 at 1:13 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > I would actually move them as far as after everything else, and right
> before the definition body. For the above function that would mean:
> >
> > func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> > where T : SequenceType,
> >   U : SequenceType,
> >   T.Generator.Element: Equatable,
> >   T.Generator.Element == U.Generator.Element
> > {
> > ...
> > }
> >
> > That would make the definition look closer to what the call site looks
> like.
> >
> > The same would work for generic types  too:
> >
> > public struct Dictionary
> > where Key : Hashable
> > {
> >...
> > }
>
> Another nice thing about this style is that, in principle, I think it
> could be extended to specify requirements on non-type parameter values.
>
> func ..< (lhs: Element, rhs: Element) ->
> Range
> where Element: Comparable, lhs <= rhs {
> …
> }
>
> I'm not saying we must or even should include that feature, merely that it
> gives us a nice syntactic slot to use if we choose to do so 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Brent Royal-Gordon via swift-evolution]

> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }

Another nice thing about this style is that, in principle, I think it could be 
extended to specify requirements on non-type parameter values.

func ..< (lhs: Element, rhs: Element) -> 
Range
where Element: Comparable, lhs <= rhs {
…
}

I'm not saying we must or even should include that feature, merely that it 
gives us a nice syntactic slot to use if we choose to do so later.

-- 
Brent Royal-Gordon
Architechies

___
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

[Ross O'Brien via swift-evolution]

It's probably appropriate. Given that, in this example, Bar implicitly
unifies its generic constraint T with Foo's associatedtype T (or,
typealiases T with T), you need to be at least a little careful how you
name your generic constraints.

protocol Foo
{
associatedtype T
}

struct Bar : Foo
{
}

On Thu, Apr 7, 2016 at 12:52 AM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think this is a good idea, though I would put the `where` clause after
> the function signature:
>
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
>
>
> A bit of a meta-argument:
>
> It is very common to use single-capital letter generic parameters, and the
> API style does not give guidance around the naming of generic parameters.
>
> However in my humble-but-opinionated view, they are effectively
> scope-bound, dynamic type aliases. Declaring func "foo" is like
> declaring “var i”, but its forgiven since coming up with a good, concise
> name for such a type alias can be hard.
>
> The standard library seems inconsistent about this as well:
>
> func == (_: (A, B), rhs: (A, B))
>
> vs.
>
> func == (_: [Key : Value], rhs: [Key :
> Value])
>
> The argument I bring up is that naming of the generic parameters may wind
> up affecting whether the code is clearer having type constraints and the
> where clause within the brackets or trailing the function. It is important
> to take this into account and compare both apples to apples and oranges to
> oranges when evaluating syntax.
>
> (or, change the API guide and standard library to discourage either apples
> or oranges)
>
> -DW
>
>
> I'll keep this short. IMO:
>
> * Dictionaries have semantics, so Key/Value makes sense.
> * Truly "generic" equatable values do not, so A and B are simple stand-ins.
> * Always prefer named tokens when there are actual semantics (Element,
> Wrapped, etc).
>
> This may or may not be appropriate for inclusion in the API guidelines.
>
> -- E
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Apr 6, 2016, at 16:52, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I think this is a good idea, though I would put the `where` clause after 
>>> the function signature:
>>> 
>>> func foo(x: T, y: U) -> Result
>>>where T.Foo == U.Bar /*, etc. */
>>> {
>>> }
>> 
>> A bit of a meta-argument:
>> 
>> It is very common to use single-capital letter generic parameters, and the 
>> API style does not give guidance around the naming of generic parameters.
>> 
>> However in my humble-but-opinionated view, they are effectively scope-bound, 
>> dynamic type aliases. Declaring func "foo" is like declaring “var i”, but 
>> its forgiven since coming up with a good, concise name for such a type alias 
>> can be hard.
>> 
>> The standard library seems inconsistent about this as well:
>> 
>> func == (_: (A, B), rhs: (A, B))
>> 
>> vs.
>> 
>> func == (_: [Key : Value], rhs: [Key : 
>> Value])
>> 
>> The argument I bring up is that naming of the generic parameters may wind up 
>> affecting whether the code is clearer having type constraints and the where 
>> clause within the brackets or trailing the function. It is important to take 
>> this into account and compare both apples to apples and oranges to oranges 
>> when evaluating syntax.
>> 
>> (or, change the API guide and standard library to discourage either apples 
>> or oranges)
>> 
>> -DW
> 
> I'll keep this short. IMO:
> 
> * Dictionaries have semantics, so Key/Value makes sense.
> * Truly "generic" equatable values do not, so A and B are simple stand-ins.
> * Always prefer named tokens when there are actual semantics (Element, 
> Wrapped, etc). 
> 
> This may or may not be appropriate for inclusion in the API guidelines.

Another factor here is that we've been planning for a while for generic 
parameters to types to be exposed as implicit member typealiases, since they 
already conflict with the namespace for member typealiases. Therefore it's 
important to name generic parameters to types well, but less important to do so 
for generic parameters for functions. (They're also much less likely to be ad 
hoc for types; there has to be something that describes the relation between 
the Self type and the parameter, while the function might not have anything 
more interesting than "operand".)

This is also a minor point against declaring generic parameters for extensions, 
since they would have to match up. We also do need a syntax some day to 
represent new parameters:

// For expository purposes only:
extension  Array where Element == Optional

But that deserves its own proposal. I just don't want us to paint ourselves 
into a corner.

Jordan

___
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]

> I (am familiar with and) agree with Dijkstra's logic, but not with your
> conclusion about it.  The fact that one representation is more natural
> for most common computing tasks doesn't mean it's not worth supporting
> the other representations.

I'm not saying that Dijkstra proves that we don't need any other range 
operators. Rather, I'm saying that he demonstrates why supporting `..<` but not 
`<..` is not arbitrary or capricious. Dijkstra's argument *permits* us to 
privilege `..<` as uniquely important, but doesn't *force* us to do so.

To another person just now, you said:

> He was talking about ranges of integer indices, though, and even
> more-specifically about how to address arrays.  Range is a more
> general concept that applies to much more than indices.  Once you
> involve floating point (and rationals, and patterns for matching,
> e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.

I actually think he was talking a little more broadly than that—essentially, he 
was discussing ordered, discrete types. In principle, the same argument applies 
to UnicodeScalars, but not to floating-point numbers (unless you use treat 
floats as a discrete type using `nextafter` as the `successor()` operation, 
which is coherent but not very useful in practice). Having said that, I *do* 
think that `...` is in practice quite useful for many types. I'm less certain 
that `<..` or `<.<` are.

* * *

By the way, another reason to have `stride` as a free function is that I think 
some types need a "strider", an instance which performs the striding.

That was the conclusion I came to when I started experimenting with striding 
over NSDates a week or two ago. The best design I could come up with looked 
like this:

calendar.using(.Day).stride(from: startDate, to: endDate, by: 1)

The `start` and `end` parameters could be grouped together into a single 
parameter to match `stride(over:by:)`, but you can't put the calendar or the 
unit into the stride—without them, there is no coherent way to calculate the 
distance between two dates.

So if some types need a strider, and will need to have the method structured as 
`strider.stride(something:by:)`, it seems like the free function version for 
types which *don't* need a strider ought to be `stride(something:by:)`. The 
`something.striding(by:)` design can't be easily adapted to this situation.

-- 
Brent Royal-Gordon
Architechies

___
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

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I think this is a good idea, though I would put the `where` clause after the 
>> function signature:
>> 
>> func foo(x: T, y: U) -> Result
>>where T.Foo == U.Bar /*, etc. */
>> {
>> }
> 
> A bit of a meta-argument:
> 
> It is very common to use single-capital letter generic parameters, and the 
> API style does not give guidance around the naming of generic parameters.
> 
> However in my humble-but-opinionated view, they are effectively scope-bound, 
> dynamic type aliases. Declaring func "foo" is like declaring “var i”, but 
> its forgiven since coming up with a good, concise name for such a type alias 
> can be hard.
> 
> The standard library seems inconsistent about this as well:
> 
> func == (_: (A, B), rhs: (A, B))
> 
> vs.
> 
> func == (_: [Key : Value], rhs: [Key : 
> Value])
> 
> The argument I bring up is that naming of the generic parameters may wind up 
> affecting whether the code is clearer having type constraints and the where 
> clause within the brackets or trailing the function. It is important to take 
> this into account and compare both apples to apples and oranges to oranges 
> when evaluating syntax.
> 
> (or, change the API guide and standard library to discourage either apples or 
> oranges)
> 
> -DW

I'll keep this short. IMO:

* Dictionaries have semantics, so Key/Value makes sense.
* Truly "generic" equatable values do not, so A and B are simple stand-ins.
* Always prefer named tokens when there are actual semantics (Element, Wrapped, 
etc). 

This may or may not be appropriate for inclusion in the API guidelines.

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

[David Waite via swift-evolution]

> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> I think this is a good idea, though I would put the `where` clause after the 
> function signature:
> 
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }

A bit of a meta-argument:

It is very common to use single-capital letter generic parameters, and the API 
style does not give guidance around the naming of generic parameters.

However in my humble-but-opinionated view, they are effectively scope-bound, 
dynamic type aliases. Declaring func "foo" is like declaring “var i”, but 
its forgiven since coming up with a good, concise name for such a type alias 
can be hard.

The standard library seems inconsistent about this as well:

func == (_: (A, B), rhs: (A, B))

vs.

func == (_: [Key : Value], rhs: [Key : 
Value])

The argument I bring up is that naming of the generic parameters may wind up 
affecting whether the code is clearer having type constraints and the where 
clause within the brackets or trailing the function. It is important to take 
this into account and compare both apples to apples and oranges to oranges when 
evaluating syntax.

(or, change the API guide and standard library to discourage either apples or 
oranges)

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 Wed Apr 06 2016, Howard Lovatt  wrote:

> Dijkstra specifically said that in Mesa it was a bad idea to include anything
> other than `..<` the relevent quote is:
>
> "Extensive experience with Mesa has shown that the use of the other three
> conventions has been a constant source of clumsiness and mistakes, and on
> account of that experience Mesa programmers are now strongly advised not to 
> use
> the latter three available features. I mention this experimental evidence —for
> what it is worth— because some people feel uncomfortable with conclusions that
> have not been confirmed in practice."
>
> In the above quote the first convention is `..<` and the other three are 
> `<..`,
> `...`, and `<.<` respectively. Therefore he is suggesting that even `...` 
> should
> not be included.

He was talking about ranges of integer indices, though, and even
more-specifically about how to address arrays.  Range is a more
general concept that applies to much more than indices.  Once you
involve floating point (and rationals, and patterns for matching,
e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.


> Personally I would go against Dijksra's advice and include all 4 as operators,
> however if Dijkstra is followed and only `..<` remains then the 'lesser' cases
> could be covered with an init on Range:
>
> init Range(first: T, isFirstIncluded: Bool = true, last: T, isLastIncluded: 
> Bool
> = true, stride: Int = 1)
>
> On Thursday, 7 April 2016, Dave Abrahams via swift-evolution
>  wrote:
>
> on Wed Apr 06 2016, Brent Royal-Gordon  wrote:
>
> >> From a purely numerically aesthetic point of view, I'd much prefer 
> ranges
> to be
> >> openable and closable at both ends.
> >>
> >> My primary use-case has been teaching math using playgrounds but I'm 
> sure
> >> there are lots of other real-world situations more specific to common
> numerical
> >> method tasks.
> >
> > By coincidence, a Perl hacker I know commented on Twitter yesterday
> > that he thought 1-based arrays were the way to go in the 21st
> > century. Somebody replying to that suggestion linked to a note by
> > Dijkstra that's relevant to this conversation:
> > 
> >
> > I'd suggest everyone in this discussion should read it—it's only about 
> 700
> words—but to summarize:
> >
> > 1. The semantic Swift refers to as `..<` is the most natural range
> convention.
> > 2. Relatedly, zero-based indexing is the most natural indexing 
> convention.
> >
> > If we agree with Dijkstra's logic, then the only reason to support
> > `>..` is for ranges where start > end—that is, when we're constructing
> > a reversed range.
>
> I (am familiar with and) agree with Dijkstra's logic, but not with your
> conclusion about it. The fact that one representation is more natural
> for most common computing tasks doesn't mean it's not worth supporting
> the other representations.
>
> > But if we decide to support striding backwards by using a forward
> > range and a negative stride, then that covers the reverse use
> > case. Thus, we would need neither additional range operators, nor
> > reversed ranges.
> >
> > As for the `range.striding(by:)` vs `stride(over:by:)` question, my
> > concerns there are, to be honest, mainly aesthetic. The need for
> > parentheses around the range operator is more or less unavoidable, but
> > I think they make the construct very ugly. However, I also think that
> > the `stride(over:by:)` syntax (or, for that matter
> > `stride(from:to:by:)`) look more constructor-y (they are only *not*
> > constructors now because of the overloading), and I think it opens us
> > up to parallel constructs like the `induce(from:while:by:)` function
> > I've been working on.
>
> --
> Dave
>
> ___
> 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] [Proposal] Threadsafe lazy vars

[Andrew Trick via swift-evolution]

> On Apr 6, 2016, at 2:07 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> lazy vars are not threadsafe in Swift 2. I saw code that uses lazy 
> initialization in an unsafe way that introduces race conditions so often that 
> I would be rich by now if get a penny each time. Many people use patterns 
> like { if(_var == nil) { _var = [self _calculateVar]; } return _var; } or 
> they just dispatch_once, but forget that they are in an instance method, and 
> that it will all break if there is ever more than one instance of that class.
> 
> I propose to make lazy vars atomic. Optionally, the old lazy var behavior 
> could be renamed to something like lazy_nonatomic.
> 
> I want to list some pros and cons for making lazy vars threadsafe:
> 
> Pros:
> - This proposal will not change the behavior of programs which are free from 
> data races. I could argue that the change is therefore backwards-compatible.
> - I would say that programs which require lazy vars to be nonatomic in order 
> to function correctly, are really bad style; threadsafe lazy vars behave much 
> more deterministic. Many programs which use lazy vars incorrectly could 
> suddenly become safe if this proposal is implemented.
> - The overhead would be minimal. For example, suppose we have a lazy var of 
> type `NSImage`. We could represent that variable as a simple pointer which is 
> initialized to NULL. The access could look something like this (this is just 
> an example, there may be even more efficient solutions): {
>// we need to make sure that reads on _var are not cached:
>memory_read_barrier(&_var);
>// ^^and I'm not 100% sure that we really need that memory barrier.
>// (at least it's not needed for static vars, as proven by the 
> implementation of dispatch_once())
> 
>if(_var == nil) {
>@synchronized(&_var) {
>// ^^we synchronize on &_var, and not on _var
>// this is semantically invalid in objc, but the objc-runtime 
> supports it.
>// The point I want to make is that we don't need extra storage 
> for the
>// synchronization, in many cases.
>if(_var != nil) {
>return _var;
>}
>... some code that initializes _var
>}
>//@synchronized() already employs memory barriers, so no additional 
> barriers are needed
>//maybe we should use a non-recursive lock though..
>}
>return _var;
> }
> - Currently, if you need threadsafety, you cannot use lazy. You can of course 
> wrap a lock around a nonatomic lazy var, but that would be much more 
> inefficient than a native implementation.
> - I guess, no one will really complain if lazy var's are suddenly threadsafe. 
> I also cannot see how it would break any code (except for contrived examples.)
> - In some cases, the nonatomic behavior can be used as an optimization, if it 
> is semantically equivalent. For example, a lazy var that lives in automatic 
> storage (i.e. not an ivar or static var, but just a local var) and that is 
> *not* captured in a closure expression can be safely initialized in a 
> non-threadsafe way, because the variable can not be accessed from more than 
> one thread concurrently anyways.
> 
> Cons:
> - This would be the first concurrency primitive built into the language (at 
> least as far as I know)
> - It may suggest to users of the language that other primitives (like var's) 
> would be threadsafe too, which is obviously not the case.
> - There is at least *some* runtime overhead involved. It's not zero-cost. On 
> the other hand, lazy initialization should only be used when the cost of 
> initialization is much higher than the cost of creating and maintaining a 
> thunk. And in that case, I think the performance characteristics are pretty 
> well.
> - It may be out of scope for Swift 3 :-(
> 
> Proposed solution:
> 
>public lazy var foo: Type = fn()
> 
> is semantically equivalent to
> 
>private var _lazy_storage_foo: Type?
>private var _lazy_lock_foo: Lock
>public var foo: Type {
>get {
>var result: Type?
>_lazy_lock_foo.withLock {
>if(_lazy_storage_foo == nil) {
>_lazy_storage_foo = fn()
>}
>}
>return _lazy_storage_foo!
>}
>}
> 
> except that the builtin solution is much more efficient, and that the two 
> private extra vars are not exposed when you use the lazy keyword.
> 
> All in all, I think that threadsafe lazy vars would be a nice feature for the 
> language. I welcome feedback and am interested in a discussion.


These are good points. I think we need both nonatomic and atomic lazy 
variables. The syntax and scaffolding will likely fall out of Property 
Behaviors:
https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md
 

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

[Howard Lovatt via swift-evolution]

Personally I would like Optional to gain `ifNil` (`??` would call
`ifNil`) and `ifNilThrow`, both of which have an auto closure argument
returning a value and throwing respectively. This would save adding an
extra operator and allow chaining to read better than `??` in some
circumstances, like when trailing closures are used, e.g:

let value = array.map { ... }
 .filter { ... }
 .firstElement
 .ifNil { ... }

Reads better than:

let value = array.map { ... }
 .filter { ... }
 .firstElement ?? { ... }

Because the `??` tends to vanish and it looks like firstElement has a
trailing closure.

On Thursday, 7 April 2016, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> I think I'm with Sean on this one. Optionals and throwing don't have
> enough to do with each other to actually come up with a specific operator
> or method for this. I can't help but see this as two ideas glued together:
>
> - "By this point in my execution I need a non-optional value, otherwise
> __"
> - "_ happened, therefore execution has failed and I should throw an
> error"
>
> …and I'm not sure these ideas coincide enough to be *worth* gluing
> together. There are a lot of other ways to get a non-optional value out of
> an optional ('??', '!', and 'guard let' with some other action), and there
> are a lot of other ways to fail besides an optional being nil (status code
> came back as error, unexpected data, connection timeout).
>
> I'd like to see some real-world examples of this before we did anything
> with it.
>
> Jordan
>
>
> On Apr 6, 2016, at 8:00, Sean Heber via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Interesting, but I’m unsure if all of it is significantly better than just
> using the guard that is effectively inside of the operator/func that is
> being proposed:
>
> guard let value = Int("NotANumber") else { throw
> InitializerError.invalidString }
>
> It is only a couple of characters longer and already works (it’s what I
> use currently). If guard allowed for a special single-expression variation
> so that you didn’t need to specify the ugly braces or something, it’d look
> prettier and be nice for a lot of other situations, too:
>
> guard let value = Int("NotANumber") else: throw
> InitializerError.invalidString
> guard someVal < 10 else: return false
> guard mustBeTrue() else: return
> // etc
>
> Not to derail this, but I sort of want this ability anywhere as a
> shorthand for a single-expression block.
>
> if something < 42: doThing()
> for a in list: print(a)
>
> But I imagine that’ll never fly. :P
>
> l8r
> Sean
>
>
>
> On Apr 6, 2016, at 9:46 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Pyry Jahkola and I have been plugging away on the following which is
> preliminary enough not to qualify as an actual draft. He prefers the Mike
> Ash approach. I prefer the operator approach. So we have not actually
> settled on which one we would actually propose despite how I've written
> this up.
>
> I'm putting this out there to try to gain a consensus on:
>
> * Would this be a viable proposal?
> * If so, which of the options would work best within Swift's design and
> philosophy
>
> Thanks for your feedback.
>
> -- Erica
> Introduction
>
> Swift's try? keyword transforms error-throwing operations into optional
> values. We propose adding an error-throwing nil-coalescing operator to the
> Swift standard library. This operator will coerce optional results into
> Swift's error-handling system.
>
> This proposal was discussed on the Swift Evolution list in the name thread.
>
> Motivation
>
> Any decision to expand Swift's set of standard operators should be taken
> thoughtfully and judiciously. Moving unaudited or deliberately
> non-error-handling nil-returning methods and failable initializers into
> Swift's error system should be a common enough use case to justify
> introducing a new operator.
>
> Detail Design
>
> We propose adding a new operator that works along the following lines:
>
> infix operator ??? {}
>
> func ???(lhs: T?, @autoclosure error: () -> ErrorType) throws -> T {
>guard case let value? = lhs else { throw error() }
>return value
> }
>
> The use-case would look like this:
>
> do {
>let error = Error(reason: "Invalid string passed to Integer
> initializer")
>let value = try Int("NotANumber") ??? InitializerError.invalidString
>print("Value", value)
> } catch { print(error) }
>
> Note
>
> SE-0047 (warn unused result by default) and SE-0049 (move autoclosure)
> both affect many of the snippets in this proposal
>
> Disadvantages to this approach:
>
> • It consumes a new operator, which developers must be trained to use
> • Unlike many other operators and specifically ??, this cannot be chained.
> There's no equivalent to a ?? b ?? c ?? dor a ?? (b ?? (c ?? d)).
> Alternati

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

[Dany St-Amant via swift-evolution]

> Le 6 avr. 2016 à 16:03, Joe Groff via swift-evolution 
>  a écrit :
> 
> 
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola  wrote:
>> 
>> Joe,
>> 
>> Just from your experience on this topic, is there any reason not to also 
>> move the primary constraints into the trailing `where` clause?
>> 
>> So instead of what you wrote, we'd have it this way:
>> 
>>func foo(x: T, y: U) -> Result
>>   where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
>>{
>>}
>> 
>> …as well as:
>> 
>>struct Foo
>>   where T: Foo, U: Bar, T.Foo == U.Bar
>>{
>>}
>> 
>> Like I said earlier in this thread, I think this would also make the 
>> `extension` syntax more uniform with types (by turning generic parameters 
>> into strictly locally visible things):
>> 
>>extension Foo where U == Baz { // (Could've used X and Y here as 
>> well.)
>>// Now it's clear where the names T and U come from.
>>var bazzes: [U] { return ... }
>>}
> 
> It's a judgment call. It's my feeling that in many cases, a generic parameter 
> is constrained by at least one important protocol or base class that's worth 
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint 
> too far from the front of the declaration.
> 

I'm with Joe here on not banning it. Having the key constraint up front seems 
make it easier to grasp the goal of the generic function with a quick glance.

Flexibility around the constraint already exist, as one can currently write:

func foo(x: C) -> C.Element

But probably few do so (maybe just because it's longer to type)

Dany
___
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

[Howard Lovatt via swift-evolution]

Dijkstra specifically said that in Mesa it was a bad idea to include
anything other than `..<` the relevent quote is:

"Extensive experience with Mesa has shown that the use of the other three
conventions has been a constant source of clumsiness and mistakes, and on
account of that experience Mesa programmers are now strongly advised not to
use the latter three available features. I mention this experimental
evidence —for what it is worth— because some people feel uncomfortable with
conclusions that have not been confirmed in practice."

In the above quote the first convention is `..<` and the other three are
`<..`, `...`, and `<.<` respectively. Therefore he is suggesting that even
`...` should not be included.

Personally I would go against Dijksra's advice and include all 4 as
operators, however if Dijkstra is followed and only `..<` remains then the
'lesser' cases could be covered with an init on Range:

init Range(first: T, isFirstIncluded: Bool =
true, last: T, isLastIncluded: Bool = true, stride: Int = 1)

On Thursday, 7 April 2016, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Apr 06 2016, Brent Royal-Gordon  > wrote:
>
> >> From a purely numerically aesthetic point of view, I'd much prefer
> ranges to be
> >> openable and closable at both ends.
> >>
> >> My primary use-case has been teaching math using playgrounds but I'm
> sure
> >> there are lots of other real-world situations more specific to common
> numerical
> >> method tasks.
> >
> > By coincidence, a Perl hacker I know commented on Twitter yesterday
> > that he thought 1-based arrays were the way to go in the 21st
> > century. Somebody replying to that suggestion linked to a note by
> > Dijkstra that's relevant to this conversation:
> > 
> >
> > I'd suggest everyone in this discussion should read it—it's only about
> 700 words—but to summarize:
> >
> >   1. The semantic Swift refers to as `..<` is the most natural range
> convention.
> >   2. Relatedly, zero-based indexing is the most natural indexing
> convention.
> >
> > If we agree with Dijkstra's logic, then the only reason to support
> > `>..` is for ranges where start > end—that is, when we're constructing
> > a reversed range.
>
> I (am familiar with and) agree with Dijkstra's logic, but not with your
> conclusion about it.  The fact that one representation is more natural
> for most common computing tasks doesn't mean it's not worth supporting
> the other representations.
>
> > But if we decide to support striding backwards by using a forward
> > range and a negative stride, then that covers the reverse use
> > case. Thus, we would need neither additional range operators, nor
> > reversed ranges.
> >
> > As for the `range.striding(by:)` vs `stride(over:by:)` question, my
> > concerns there are, to be honest, mainly aesthetic. The need for
> > parentheses around the range operator is more or less unavoidable, but
> > I think they make the construct very ugly. However, I also think that
> > the `stride(over:by:)` syntax (or, for that matter
> > `stride(from:to:by:)`) look more constructor-y (they are only *not*
> > constructors now because of the overloading), and I think it opens us
> > up to parallel constructs like the `induce(from:while:by:)` function
> > I've been working on.
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
___
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

[Michael M. Mayer via swift-evolution]

I am opposed to any change to the current access level system.  
What we have now is simple, approachable and handles all real cases 
for limiting or granting access.  Any additions will just serve to 
complicate the current system without sufficient offsetting benefit.  
Further additions will just handle cases for which there are already 
other viable solutions.

Furthermore, any additions to the access level system would be contrary 
to the stated goal of streamlining the Swift language.

Thank you for the opportunity to contribute to the discussion.

Regards, Michael
m.may...@gmail.com

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Evan Maloney via swift-evolution]

> Agreed.  Let me ask the question differently: what value does the 
> leading `.` provide to the user of the language?


I find the leading-dot syntax to be very useful; it's a pretty clear shorthand 
that I'm not referencing something at global scope.

Here's a common example from our codebase:

completion(.Failed(.wrap(error)))

The completion function takes an enum value of type DataTransactionResult, of 
which .Failed is one case. The .Failed case takes an associated value of type 
DataTransactionError, which has a static function called wrap() that accepts an 
ErrorType and returns a DataTransactionError containing it.

Although .Failed is being used here in the common enum shorthand style, being 
able to very quickly determine that wrap() is not a global function is helpful. 
Without the leading dot, some context disappears:

completion(Failed(wrap(error)))

Now, it's a lot harder to tell what I'm dealing with.

What is 'Failed'? Is it a class with an initializer that we're passing the 
result of wrap(error) to? Or is it an enum case with an associated type? 
Further, what's wrap()? A function in the global scope? Sure looks like it!

If we got rid of the shorthand altogether, we end up with something much more 
verbose:

completion(DataTransactionResult.Failed(DataTransactionError.wrap(error)))

Yes, it's more explicit, but I would not necessarily argue that it's easier to 
read.

___
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 Wed Apr 06 2016, Brent Royal-Gordon  wrote:

>> From a purely numerically aesthetic point of view, I'd much prefer ranges to 
>> be 
>> openable and closable at both ends. 
>> 
>> My primary use-case has been teaching math using playgrounds but I'm sure 
>> there are lots of other real-world situations more specific to common 
>> numerical
>> method tasks.
>
> By coincidence, a Perl hacker I know commented on Twitter yesterday
> that he thought 1-based arrays were the way to go in the 21st
> century. Somebody replying to that suggestion linked to a note by
> Dijkstra that's relevant to this conversation:
> 
>
> I'd suggest everyone in this discussion should read it—it's only about 700 
> words—but to summarize:
>
>   1. The semantic Swift refers to as `..<` is the most natural range 
> convention.
>   2. Relatedly, zero-based indexing is the most natural indexing 
> convention.
>
> If we agree with Dijkstra's logic, then the only reason to support
> `>..` is for ranges where start > end—that is, when we're constructing
> a reversed range. 

I (am familiar with and) agree with Dijkstra's logic, but not with your
conclusion about it.  The fact that one representation is more natural
for most common computing tasks doesn't mean it's not worth supporting
the other representations.

> But if we decide to support striding backwards by using a forward
> range and a negative stride, then that covers the reverse use
> case. Thus, we would need neither additional range operators, nor
> reversed ranges.
>
> As for the `range.striding(by:)` vs `stride(over:by:)` question, my
> concerns there are, to be honest, mainly aesthetic. The need for
> parentheses around the range operator is more or less unavoidable, but
> I think they make the construct very ugly. However, I also think that
> the `stride(over:by:)` syntax (or, for that matter
> `stride(from:to:by:)`) look more constructor-y (they are only *not*
> constructors now because of the overloading), and I think it opens us
> up to parallel constructs like the `induce(from:while:by:)` function
> I've been working on.

-- 
Dave

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

Re: [swift-evolution] Generic Alaises

[Milos Rankovic via swift-evolution]

Hi Ross,

That was a hell of an example! However, even with the types as they are now, 
the code needn’t look so dreadful. With following protocols in place:

protocol Indexed {
associatedtype Index : Hashable
var index: Index { get }
}

protocol NodeType : Indexed { }
protocol EdgeType: Indexed { }

protocol GraphType {
associatedtype Node : NodeType
associatedtype Edge : EdgeType

var nodes: [Node] { get }
var edges: [Edge] { get }
}

We can define `Graph` and `Path` as:

struct Graph : GraphType {
let nodes: [Node] = [] // todo
let edges: [Edge] = [] // todo
}

struct Path {}

So the function with the endless signature you’ve got would become:

extension Graph {
func shortestPath(from from: Node, to: Node) -> Path {
fatalError("todo")
}
}

As for my link to Chris’s proposal, all I meant is to point out that there is a 
proposal under review with an identical name as this thread. I certainly did 
not mean to discourage discussion James started!

milos

> On 6 Apr 2016, at 21:45, Ross O'Brien  wrote:
> 
> It's not the same topic. Let's take an example: suppose we have a data 
> structure for a graph of nodes and edges, where the nodes and edges are 
> indexed and both have values. So we have a Graph EdgeIndex : Hashable, NodeValue, EdgeValue>.
> Now suppose we want a shortest path from one node to another, and we have a 
> data structure to represent that. Now we have a Path EdgeIndex : Hashable, NodeValue, EdgeValue>. They both have the same 'generic 
> signature'. If you're navigating a Graph, you're 
> going to want a Path as output.
> 
> Right now you might write that as:
> func shortestPath EdgeValue>(graph:Graph, 
> startNode: NodeIndex, endNode: NodeIndex> -> Path NodeValue, EdgeValue>
> 
> It might save a fair amount of typing if we had a generic equivalent to both 
> typealias and associatedtype.
> 
> associatedgenerics GraphElements =  Hashable, NodeValue, EdgeValue>
> func shortestPath(graph: Graph, 
> startNode, endNode) -> 
> Path
> 
> genericalias NavigationGraphElements = GraphElements Motorway>
> 
> typealias NavigationGraph = Graph
> // navigationGraph.shortestPath() now returns a Path
> // this last part is closest to the proposal under review.
> 
> 
> On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Chris Lattner has a proposal under review 
> 
>  on this topic. 
> 
> milos
> 
>> On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> This was inspired from the topic about moving where clauses out of parameter 
>> lists.
>> 
>> Certain generics get very long winded, I was wondering if we could create 
>> some sort of alias for generics.
>> 
>> func anyCommonElements > T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> could be shared across functions like so:
>> 
>> genericalias SequencesWithSameElements =  > SequenceType where T.Generator.Element: Equatable, T.Generator.Element == 
>> U.Generator.Element>
>> 
>> func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
>> func ==  (lhs: T, _ rhs: U) -> Bool
>> ___
>> 
>> James⎥
>> 
>> ja...@supmenow.com ⎥supmenow.com 
>> 
>> Sup
>> 
>> Runway East
>> 
>> 
>> 10 Finsbury Square
>> 
>> London
>> 
>> 
>> EC2A 1AF 
>> 
>> ___
>> 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] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

Hi Milos

Yes,  (v1…v2).by(v3)  it can determine the going of either in  + or - direction,
but only at run time! because the contents of v1, v2, v3 are of course unknown 
at compile time. 
Ergo: it cannot expected be an absolute value.

however, I suggested (coded) that here on 4.3.2016…  Works in Playground Xcode 
7.3
look in the struct its “init”   where the direction is determined
by wether “from” or “to” is bigger” 
implemented like this  (and also with a floating point number tolerance)
(The struct should be numerical generic, but I didn’t manage to change it to 
generic,) 
Anyway, should be compilerized/hand coded in asm perhaps (I can’t do that)

TedvG

public struct StriderGenerator : GeneratorType
{
private let low: Double
private let high: Double
private var step : Double
private var tol  : Double

private var iterator  = 0

private let moveForward: Bool

private var done  = false


public init(from: Double, to: Double, by: Double, tolerance: Double)
{
step = by
if from < to
{
low  = from
high = to
moveForward = true
}
else
{
low  = to
high = from
moveForward = false
}
self.tol   = tolerance * 0.5  // center it.
}

/// return next value or nil, if no next
/// element exists.

public mutating func next() -> Double?
{
let current:Double
if done
{
return nil
}

if moveForward
{
current = low + Double(iterator) * step
}
else
{
current = high - Double(iterator) * step
}
iterator += 1


// done if exceeding low or high limits + tolerance

done = current > high   + tol  ||
   current < low- tol

if done
{
return nil
}
else
{
return current
}
}
}

public struct Strider : SequenceType   // Aragorn
{
private let start:  Double
private let end:Double
private let step:   Double
private let tol:Double

init(from: Double, to: Double, by: Double, tolerance : Double)
{
_precondition(by > 0.0 ,
"Init of struct Strider: 'by:...' value must be > 0.0.")
_precondition(abs(by) > tolerance,
"Init of struct Strider: 'by:...' value must be > tolerance.")
_precondition(tolerance >= 0.0,
"Init of struct Strider: tolerance:... value must be >= 0.0")

start = from
end   = to;
step  = by
tol   = tolerance
}

/// Return a *generator* over the elements of this *sequence*.

public func generate() -> StriderGenerator
{
return StriderGenerator(from: start, to: end, by: step, tolerance:  tol)
}
}

public extension Double
{

public func strider(to to: Double, by: Double, tolerance: Double ) -> 
Strider
{
return Strider( from: self, to: to, by: by, tolerance: tolerance)
}
}

print("Testing the new .strider extension")

let testvalues =
[
// fr: to: by:   tolerance:
[ 0.0, 5.0,1.0,0.0 ],
[-3.0, 4.0,0.12,   0.1 ],
[ 2.0,-1.0,0.34,   0.1  ],
[ 0.001,  -0.002,  0.0001, 0.1 ]
]

for parm in testvalues
{

print("==Stride from: \(parm[0]) to: \(parm[1]) by: \(parm[2]) 
tolerance: \(parm[3])\n")

for val in parm[0].strider(to: parm[1], by: parm[2], tolerance: parm[3])
{
print("\(val) ", terminator:"")
}
print("\n\n")
}




TedvG



> On 06.04.2016, at 23:15, Milos Rankovic  wrote:
> 
> Hi Ted,
> 
>> that would imply the ‘by”value should/must always be an absolute value?
> 
> 
> In a way: Instead of `Strideable.Stride` I would suggest 
> `Strideable.Distance`.
> 
> At any rate, leaving the sign to be direction indicator makes it forever 
> necessary for everyone to make this counterintuitive metal gymnastics, since 
> most of the time in life we do not walk backwards, even when we are returning 
> back whence we came from!
> 
> What do you think?
> 
> milos
> 
> 
>> On 6 Apr 2016, at 21:34, Ted F.A. van Gaalen > > wrote:
>> 
>> Hello Milos,
>> Good question
>> was thinking about this too.
>> that would imply the ‘by”value should/must always be an absolute value?
>> however (if it is a var) it cannot be guaranteed to be + or - 
>> that’s why I thought to leave it as is.
>> ?
>> TedvG
>> 
>>> On 06.04.2016, at 22:18, Milos Rankovic >> > wrote:
>>> 
>>> 
 On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 v1 >  v2:   is allowed and correctly evaluated.  e.g. 
 (8.0…-3.14159).by(-0.0001) 
>>> 
>>> If the range does not assume `st

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

[Dave Abrahams via swift-evolution]

on Wed Apr 06 2016, Erica Sadun  wrote:

> On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Wed Apr 06 2016, Xiaodi Wu  wrote:
>
> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> You if you need to represent `<..` intervals in scientific computing,
> that's a pretty compelling argument for supporting them.
>
> I'd like to be able to represent any of those as
> Intervals-which-are-now-Ranges. It makes sense to do so 
> because
> the
> things I want to do with them, such as clamping and testing if
> some
> value is contained, are exactly what Intervals-now-Ranges
> provide.
> Looking around, it seems many other languages provide only 
> what
> Swift
> currently does, but Perl does provide `..`, `..^`, `^..`, and
> `^..^`
> (which, brought over to Swift, would be `...`, `..<`, `<..`, 
> and
> `<.<`).
>
> Do we need fully-open ranges too?
>
> I haven't encountered a need for open ranges, but I would expect that
> other applications in scientific computing could make use of them.
> I rather like Pyry's suggestions below. 
>
> Below?
>
> Logically in time below.

Oh! In my application, time flows downward.

>
> I believe the following is a valid conversion of the Xiaodi Wu below into the
> Dave A domain.
>
> On Apr 6, 2016, at 2:29 PM, Pyry Jahkola via swift-evolution
>  wrote:
>
> I think a sensible specification would be that with a positive step size,
> the count starts from the lower bound, and with a negative one, it starts
> from the upper bound (inclusive or exclusive). Thus, the following 
> examples
> should cover all the corner cases:
>
> (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]

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
___
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]

> From a purely numerically aesthetic point of view, I'd much prefer ranges to 
> be 
> openable and closable at both ends. 
> 
> My primary use-case has been teaching math using playgrounds but I'm sure 
> there are lots of other real-world situations more specific to common 
> numerical
> method tasks.

By coincidence, a Perl hacker I know commented on Twitter yesterday that he 
thought 1-based arrays were the way to go in the 21st century. Somebody 
replying to that suggestion linked to a note by Dijkstra that's relevant to 
this conversation: 


I'd suggest everyone in this discussion should read it—it's only about 700 
words—but to summarize:

1. The semantic Swift refers to as `..<` is the most natural range 
convention.
2. Relatedly, zero-based indexing is the most natural indexing 
convention.

If we agree with Dijkstra's logic, then the only reason to support `>..` is for 
ranges where start > end—that is, when we're constructing a reversed range. But 
if we decide to support striding backwards by using a forward range and a 
negative stride, then that covers the reverse use case. Thus, we would need 
neither additional range operators, nor reversed ranges.

As for the `range.striding(by:)` vs `stride(over:by:)` question, my concerns 
there are, to be honest, mainly aesthetic. The need for parentheses around the 
range operator is more or less unavoidable, but I think they make the construct 
very ugly. However, I also think that the `stride(over:by:)` syntax (or, for 
that matter `stride(from:to:by:)`) look more constructor-y (they are only *not* 
constructors now because of the overloading), and I think it opens us up to 
parallel constructs like the `induce(from:while:by:)` function I've been 
working on.

-- 
Brent Royal-Gordon
Architechies

___
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 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

> On Apr 6, 2016, at 1:35 PM, Douglas Gregor  > wrote:
> 
> Fortunately, Swift tells you when you get it wrong.

It doesn't, though.  That's the thing.

Consider CloudKit, first available in iOS 8.  Does that framework's 
implementation rely on new, novel APIs only available on iOS 8, and the Swift 
compiler threw availability errors to the implementor of CloudKit?  Or, is the 
reason the reason it's "unavailable" in 7 because Apple decided as a point of 
business not to compile, test, and QA an iOS 7.3 that added CloudKit?  Well I 
don't have the sourcecode so I don't know, maybe there is some incredibly novel 
API involved in talking to computers on the internet not available in iOS 7.  
But I suspect it's mostly a business decision, not technical.

So, if we assume that's the case (or, if I'm wrong, replace CK with a framework 
for which there is no technical reason why it's unavailable), then Apple paid 
some QA engineer to sprinkle @available on all the public APIs.  Meanwhile, 
third-party developers in this situation are similarly making business 
decisions not to support iOS 7/8, and we also have to grab our QA engineer and 
comb through the API very carefully.

I'm suggesting is we can all fire the QA engineer with a compiler feature.

> Really, this syntax is a shorthand for “treat the imported library as if the 
> author had put this availability annotation on all of its public APIs”.

What if we solve the problem at "framework-compile-time" rather than at 
"import-time"?

Suppose we have some driver flag that injects @availability onto every decl in 
the module.  For decls with existing @availability it simply raises the floor 
to some minimum value.  Now we distribute the module, and the availabilities 
have been set.

My intuition would be to use the existing "deployment target" flag to control 
this feature, since this is how framework authors actually do express their 
intent to support an OS.  But if we need to introduce a novel concept of an 
"availability target", that's fine too.

The important thing is that it's zero-effort for consumers of the framework, 
and I get to fire my QA engineer.

___
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: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.

-- E

___
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

[Stephen Canon via swift-evolution]

> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 06 2016, Erica Sadun  wrote:
> 
>>On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>on Wed Apr 06 2016, Xiaodi Wu  wrote:
>> 
>>On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>You if you need to represent `<..` intervals in scientific computing,
>>that's a pretty compelling argument for supporting them.
>> 
>>I'd like to be able to represent any of those as
>>Intervals-which-are-now-Ranges. It makes sense to do so 
>> because
>>the
>>things I want to do with them, such as clamping and testing if
>>some
>>value is contained, are exactly what Intervals-now-Ranges
>>provide.
>>Looking around, it seems many other languages provide only 
>> what
>>Swift
>>currently does, but Perl does provide `..`, `..^`, `^..`, and
>>`^..^`
>>(which, brought over to Swift, would be `...`, `..<`, `<..`, 
>> and
>>`<.<`).
>> 
>>Do we need fully-open ranges too?
>> 
>>I haven't encountered a need for open ranges, but I would expect that
>>other applications in scientific computing could make use of them.
>>I rather like Pyry's suggestions below. 
>> 
>>Below?
>> 
>> Logically in time below.
> 
> Oh! In my application, time flows downward.
> 
>> 
>> I believe the following is a valid conversion of the Xiaodi Wu below into the
>> Dave A domain.
>> 
>>On Apr 6, 2016, at 2:29 PM, Pyry Jahkola via swift-evolution
>> wrote:
>> 
>>I think a sensible specification would be that with a positive step size,
>>the count starts from the lower bound, and with a negative one, it starts
>>from the upper bound (inclusive or exclusive). Thus, the following 
>> examples
>>should cover all the corner cases:
>> 
>>(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]
> 
> These all look reasonable to me.

Agreed.

– Steve

___
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

[Milos Rankovic via swift-evolution]

Hi Ted,

> that would imply the ‘by”value should/must always be an absolute value?


In a way: Instead of `Strideable.Stride` I would suggest `Strideable.Distance`.

At any rate, leaving the sign to be direction indicator makes it forever 
necessary for everyone to make this counterintuitive metal gymnastics, since 
most of the time in life we do not walk backwards, even when we are returning 
back whence we came from!

What do you think?

milos


> On 6 Apr 2016, at 21:34, Ted F.A. van Gaalen  wrote:
> 
> Hello Milos,
> Good question
> was thinking about this too.
> that would imply the ‘by”value should/must always be an absolute value?
> however (if it is a var) it cannot be guaranteed to be + or - 
> that’s why I thought to leave it as is.
> ?
> TedvG
> 
>> On 06.04.2016, at 22:18, Milos Rankovic > > wrote:
>> 
>> 
>>> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
>>> (8.0…-3.14159).by(-0.0001) 
>> 
>> If the range does not assume `start >= end`, is it still necessary to also 
>> indicate the traversal direction with the sign of the step (`-0.0001`)?
>> 
>> milos
> 

___
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

[Xiaodi Wu via swift-evolution]

On Wed, Apr 6, 2016 at 4:05 PM, Dave Abrahams  wrote:
>
> on Wed Apr 06 2016, Xiaodi Wu  wrote:
>
>> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>>  wrote:
>>> You if you need to represent `<..` intervals in scientific computing,
>>> that's a pretty compelling argument for supporting them.
>>>
 I'd like to be able to represent any of those as
 Intervals-which-are-now-Ranges. It makes sense to do so because the
 things I want to do with them, such as clamping and testing if some
 value is contained, are exactly what Intervals-now-Ranges provide.
 Looking around, it seems many other languages provide only what Swift
 currently does, but Perl does provide `..`, `..^`, `^..`, and `^..^`
 (which, brought over to Swift, would be `...`, `..<`, `<..`, and
 `<.<`).
>>>
>>> Do we need fully-open ranges too?
>>
>> I haven't encountered a need for open ranges, but I would expect that
>> other applications in scientific computing could make use of them.
>> I rather like Pyry's suggestions below.
>
> Below?

Sorry, chronologically, above; in terms of relative positions in the
thread, I think, below, since Pyry's suggests followed on from the
time I started writing. Ha, and Erica (above/below) just filled in
what I meant to say.
___
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 Wed Apr 06 2016, Erica Sadun  wrote:

> On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> Guidance:
>
> When using odd integer literals to produce an even number sequence,
> prefer the `...` operator to the `..<` operator and change your ending
> literal to an even number.
>
> I don't think you can fix counterintuitive behavior with guidance. 
>
> (1..<199).striding(by: -2) is the first way I'd reach for to express
> 197, 195, ..., 3, 1
>
> Yes, but you can with warnings and fixits. 
>
> * The compiler should issue a warning for any use of 
>
> (n..
> with a fixit of "replace (n.. whether n or m is known at compile time 
>
> * If v cannot be known at compile time, I think the compiler should
> always prefer ... to ..<.
>
> * The compiler should not allow
>
> (n..
> where v is known at compile time to be a negative constant. There should 
> also be a runtime precondition that raises a fatal error should a negative 
> v be used with a half-open interval.

You can lessen the impact of any design choice by adding warnings and
fixits, but I'm pretty sure it's better to make a choice that doesn't
require them.

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

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Apr 06 2016, Xiaodi Wu  > wrote:
> 
>> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>>  wrote:
>>> You if you need to represent `<..` intervals in scientific computing,
>>> that's a pretty compelling argument for supporting them.
>>> 
 I'd like to be able to represent any of those as
 Intervals-which-are-now-Ranges. It makes sense to do so because the
 things I want to do with them, such as clamping and testing if some
 value is contained, are exactly what Intervals-now-Ranges provide.
 Looking around, it seems many other languages provide only what Swift
 currently does, but Perl does provide `..`, `..^`, `^..`, and `^..^`
 (which, brought over to Swift, would be `...`, `..<`, `<..`, and
 `<.<`).
>>> 
>>> Do we need fully-open ranges too?
>> 
>> I haven't encountered a need for open ranges, but I would expect that
>> other applications in scientific computing could make use of them.
>> I rather like Pyry's suggestions below. 
> 
> Below?

Logically in time below.

I believe the following is a valid conversion of the Xiaodi Wu below into the 
Dave A domain.

> On Apr 6, 2016, at 2:29 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> I think a sensible specification would be that with a positive step size, the 
> count starts from the lower bound, and with a negative one, it starts from 
> the upper bound (inclusive or exclusive). Thus, the following examples should 
> cover all the corner cases:
> 
> (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]
> 
> Lastly, if you want the positive stride reversed, you'd do just that:
> 
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
> 
> — Pyry

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

[swift-evolution] [Proposal] Threadsafe lazy vars

[Michael Peternell via swift-evolution]

Hi all,

lazy vars are not threadsafe in Swift 2. I saw code that uses lazy 
initialization in an unsafe way that introduces race conditions so often that I 
would be rich by now if get a penny each time. Many people use patterns like { 
if(_var == nil) { _var = [self _calculateVar]; } return _var; } or they just 
dispatch_once, but forget that they are in an instance method, and that it will 
all break if there is ever more than one instance of that class.

I propose to make lazy vars atomic. Optionally, the old lazy var behavior could 
be renamed to something like lazy_nonatomic.

I want to list some pros and cons for making lazy vars threadsafe:

Pros:
- This proposal will not change the behavior of programs which are free from 
data races. I could argue that the change is therefore backwards-compatible.
- I would say that programs which require lazy vars to be nonatomic in order to 
function correctly, are really bad style; threadsafe lazy vars behave much more 
deterministic. Many programs which use lazy vars incorrectly could suddenly 
become safe if this proposal is implemented.
- The overhead would be minimal. For example, suppose we have a lazy var of 
type `NSImage`. We could represent that variable as a simple pointer which is 
initialized to NULL. The access could look something like this (this is just an 
example, there may be even more efficient solutions): {
// we need to make sure that reads on _var are not cached:
memory_read_barrier(&_var);
// ^^and I'm not 100% sure that we really need that memory barrier.
// (at least it's not needed for static vars, as proven by the 
implementation of dispatch_once())

if(_var == nil) {
@synchronized(&_var) {
// ^^we synchronize on &_var, and not on _var
// this is semantically invalid in objc, but the objc-runtime 
supports it.
// The point I want to make is that we don't need extra storage for 
the
// synchronization, in many cases.
if(_var != nil) {
return _var;
}
... some code that initializes _var
}
//@synchronized() already employs memory barriers, so no additional 
barriers are needed
//maybe we should use a non-recursive lock though..
}
return _var;
}
- Currently, if you need threadsafety, you cannot use lazy. You can of course 
wrap a lock around a nonatomic lazy var, but that would be much more 
inefficient than a native implementation.
- I guess, no one will really complain if lazy var's are suddenly threadsafe. I 
also cannot see how it would break any code (except for contrived examples.)
- In some cases, the nonatomic behavior can be used as an optimization, if it 
is semantically equivalent. For example, a lazy var that lives in automatic 
storage (i.e. not an ivar or static var, but just a local var) and that is 
*not* captured in a closure expression can be safely initialized in a 
non-threadsafe way, because the variable can not be accessed from more than one 
thread concurrently anyways.

Cons:
- This would be the first concurrency primitive built into the language (at 
least as far as I know)
- It may suggest to users of the language that other primitives (like var's) 
would be threadsafe too, which is obviously not the case.
- There is at least *some* runtime overhead involved. It's not zero-cost. On 
the other hand, lazy initialization should only be used when the cost of 
initialization is much higher than the cost of creating and maintaining a 
thunk. And in that case, I think the performance characteristics are pretty 
well.
- It may be out of scope for Swift 3 :-(

Proposed solution:

public lazy var foo: Type = fn()

is semantically equivalent to

private var _lazy_storage_foo: Type?
private var _lazy_lock_foo: Lock
public var foo: Type {
get {
var result: Type?
_lazy_lock_foo.withLock {
if(_lazy_storage_foo == nil) {
_lazy_storage_foo = fn()
}
}
return _lazy_storage_foo!
}
}

except that the builtin solution is much more efficient, and that the two 
private extra vars are not exposed when you use the lazy keyword.

All in all, I think that threadsafe lazy vars would be a nice feature for the 
language. I welcome feedback and am interested in a discussion.

Regards,
Michael

___
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 Wed Apr 06 2016, Xiaodi Wu  wrote:

> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
>  wrote:
>> You if you need to represent `<..` intervals in scientific computing,
>> that's a pretty compelling argument for supporting them.
>>
>>> I'd like to be able to represent any of those as
>>> Intervals-which-are-now-Ranges. It makes sense to do so because the
>>> things I want to do with them, such as clamping and testing if some
>>> value is contained, are exactly what Intervals-now-Ranges provide.
>>> Looking around, it seems many other languages provide only what Swift
>>> currently does, but Perl does provide `..`, `..^`, `^..`, and `^..^`
>>> (which, brought over to Swift, would be `...`, `..<`, `<..`, and
>>> `<.<`).
>>
>> Do we need fully-open ranges too?
>
> I haven't encountered a need for open ranges, but I would expect that
> other applications in scientific computing could make use of them.
> I rather like Pyry's suggestions below. 

Below?

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

Re: [swift-evolution] Notes from Swift core team 2016-04-05 design discussion

[Michael Ilseman via swift-evolution]

I don’t think the notes were conveying a decided-upon solution, so much as a 
fervent discussion which did not yet yield a conclusion. If you have an idea of 
how to address this, could you put together a draft?

> On Apr 6, 2016, at 3:39 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Great solution for C interop! Eventually, annotations for C language and API 
> notes could be replaced with such 
> automatically-generated-manually-correctable bridge files.
> We could support a wide range of conversions for @shadowing_c, such as 
> convertion of IUO to optional or unwrapped type.
> There could also be a CBridgeable protocol (like ObjectiveCBridgeable) to 
> convert Swift data types to ones imported from C. @shadowing_c should support 
> such convertions.
> Better yet, just rename ObjectiveCBridgeable to Bridgeable, and call new 
> annotation @shadowingImport. Support for other languages, for example, C++, 
> can theoretically be added later.
> ___
> 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

[Xiaodi Wu via swift-evolution]

On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution
 wrote:
> You if you need to represent `<..` intervals in scientific computing,
> that's a pretty compelling argument for supporting them.
>
>> I'd like to be able to represent any of those as
>> Intervals-which-are-now-Ranges. It makes sense to do so because the
>> things I want to do with them, such as clamping and testing if some
>> value is contained, are exactly what Intervals-now-Ranges provide.
>> Looking around, it seems many other languages provide only what Swift
>> currently does, but Perl does provide `..`, `..^`, `^..`, and `^..^`
>> (which, brought over to Swift, would be `...`, `..<`, `<..`, and
>> `<.<`).
>
> Do we need fully-open ranges too?

I haven't encountered a need for open ranges, but I would expect that
other applications in scientific computing could make use of them.
I rather like Pyry's suggestions below. These would represent an
expansive fleshing out of ranges. They really start pulling their
weight for floating point bounds; of course, I'd wager that ... and
..< would still be the most used by far.
___
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 Wed Apr 06 2016, Erica Sadun  wrote:

>> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu  wrote:
>> Prohibiting StrideTo with floating-point ranges altogether would be
>> distressing. IMO, it's plenty distressing that backwards
>> floating-point StrideTo as it currently exists might go away.
>
> I wouldn't suggest doing so. I'm just saying that for a half-open interval, 
> there is no max value
> so it makes no sense mathematically to have a first value and a
> negative step. 

I don't agree.  It seems to me that striding downwards over a half-open
range r should always begin with r.upperBound - s (modulo any necessary
adjustments to avoid FP error), where -s is the stride amount.  Why is
that mathematical nonsense?

Another point to consider: striding is also a sensible operation over
collections, and some ranges are collections.  The stride semantics must
coincide in those cases.  I expect that constraint narrows down the
reasonable semantic choices considerably.

> You're not so restricted with:
>
> * positive steps
> * closed intervals
>
> -- E
>
> ___
> 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] Generic Alaises

[James Campbell via swift-evolution]

Ross put it better than I ever could :) yes this is what I meant 

Sent from Supmenow.com




On Wed, Apr 6, 2016 at 1:45 PM -0700, "Ross O'Brien" 
 wrote:










It's not the same topic. Let's take an example: suppose we have a data 
structure for a graph of nodes and edges, where the nodes and edges are indexed 
and both have values. So we have a Graph.Now suppose we want a shortest path from one 
node to another, and we have a data structure to represent that. Now we have a 
Path. They 
both have the same 'generic signature'. If you're navigating a Graph, you're going to want a Path 
as output.
Right now you might write that as:func shortestPath(graph:Graph, 
startNode: NodeIndex, endNode: NodeIndex> -> Path
It might save a fair amount of typing if we had a generic equivalent to both 
typealias and associatedtype.
associatedgenerics GraphElements = func shortestPath(graph: 
Graph, startNode, 
endNode) -> Path
genericalias NavigationGraphElements = GraphElements
typealias NavigationGraph = Graph// 
navigationGraph.shortestPath() now returns a Path// 
this last part is closest to the proposal under review.

On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution 
 wrote:
Chris Lattner has a proposal under review on this topic. 
milos

On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
 wrote:
This was inspired from the topic about moving where clauses out of parameter 
lists.
Certain generics get very long winded, I was wondering if we could create some 
sort of alias for generics.
func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool

could be shared across functions like so:
genericalias SequencesWithSameElements =  
func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
func ==  (lhs: T, _ rhs: U) -> Bool


___

James⎥

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

Sup

Runway East


10 Finsbury Square

London


EC2A 1AF 

___
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] Generic Alaises

[Ross O'Brien via swift-evolution]

It's not the same topic. Let's take an example: suppose we have a data
structure for a graph of nodes and edges, where the nodes and edges are
indexed and both have values. So we have a Graph.
Now suppose we want a shortest path from one node to another, and we have a
data structure to represent that. Now we have a Path. They both have the same
'generic signature'. If you're navigating a Graph, you're going to want a Path as
output.

Right now you might write that as:
func shortestPath(graph:Graph,
startNode: NodeIndex, endNode: NodeIndex> -> Path

It might save a fair amount of typing if we had a generic equivalent to
both typealias and associatedtype.

associatedgenerics GraphElements = 
func shortestPath(graph: Graph,
startNode, endNode) ->
Path

genericalias NavigationGraphElements = GraphElements

typealias NavigationGraph = Graph
// navigationGraph.shortestPath() now returns a
Path
// this last part is closest to the proposal under review.


On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution <
swift-evolution@swift.org> wrote:

> Chris Lattner has a proposal under review
> 
>  on
> this topic.
>
> milos
>
> On 6 Apr 2016, at 20:41, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This was inspired from the topic about moving where clauses out of
> parameter lists.
>
> Certain generics get very long winded, I was wondering if we could create
> some sort of alias for generics.
>
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element>
> (lhs: T, _ rhs: U) -> Bool
>
> could be shared across functions like so:
>
> genericalias SequencesWithSameElements =   SequenceType where T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element>
>
> func anyCommonElements  (lhs: T, _ rhs: U) ->
> Bool
> func ==  (lhs: T, _ rhs: U) -> Bool
>
> *___*
>
> *James⎥*
>
> *ja...@supmenow.com ⎥supmenow.com
> *
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
> ___
> 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] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

G Typos… Sorry, here it is again: vital  correctionslook at<< 
<

Hi Erica, Dave

Based on what I’ve (not all) read under this topic: 

I’d suggest a more complete approach:

Ranges should support:  (as yet not implemented) 

- All numerical data types (Double, Float, Int, Money***, Decimal*** ) 
- An arbitrary increment or decrement value.
- Working in the complete  - + numerical range
- Allow traversing in both   - + directions.



The basics:

(v1…v2).by(v3) // this still is readable. and can be optimized by the 
compiler (predictable sequence)

Rules:

v1, v2, v3  are any numerical type scalar type  
v1, v2, v3  must have the same numerical type.
v1 >  v2:   is allowed and correctly evaluated.  e.g. 
(8.0…-3.14159).by(-0.0001) 


The  ..<  half open operator is no longer allowed.   write e.g.   
0...ar.count - 1

"by(…)”  is obligatory with floating point range.

   the default “by(…)” value of 1 makes sense only with integer ranges.


valid examples:
(5…9)// 5 6 7 8 9 Integer range without “by” 
defaults to 1 as increment value.
(1...10).by(2) // 1 3 5 7 9.
(2...10).by(2) // 2 4 6 8 10.
(4…-4).by(-2) // 4  2 0 -2 -4 .// runs backwards
  <<<
(30..-10).by(-2)// 30 28 26 24 22 ….. -10.
(10...0).by(-3)  // 10 7 4 1. 

(12…-10) // is valid, but returns empty because default 
increment value = 1

(12.0…-12.0).by(-1.5)   // 12.0  10.5  9.0….  // of course with 
float imprecision
   
   

   invalid examples:

   (23.0..<60.5).by(0.5) // half open ranges are no  longer allowed ** 
  (23.0…60.5) // “ by"  is obligatory with floats.
  (14...8).by(0.5)//  v1 v2 and v3 don’t have the same 
numerical type 


Half open ranges make no real sense (are not really useful) with floating point 
values.
and no sense at all with e.g (12..<-1)  afaics 


At least for float iterations the increment value should not each time be 
accumulated like
v1 += v3;  v1 += v3;  v1 += v3;  ….   // causes float 
number drift.
but be freshly multiplied with each iteration, e.g. by using an internal 
iteration counter
like so:

v = v1 + v3 * i++; v = v1 + v3 * i++;  v = v1 + v3 * i++;  v = v1 + v3 
* i++; <<<

for reasons of precision.

If one has worked with floating point data more often
awareness of its precision limitations become a second nature conscience. 
E.g. it is perfectly acceptable and known (also in classical for-loops) that
(0.0…1.0).by(0.1) is not guaranteed to reach the humanly expected value of 1.0.
This is normal. Due to the nature of what mostly is done in the
floating point numbers domain, this does not often cause a problem
(e.g like working with a slide ruler) 
if it is important to reach the “expected end” then one could
-add an epsilon value like so (v1…v2 + 0.1) 
-generate the desired float sequence within an integer loop.


The above “range” (imho) improvement makes the 
stride.. function/keyword completely unnecessary.

Due to its ability to process reversed ranges as is, 
the .reverse() is optional (no longer necessary in most cases,
allowing the compiler to optimize without having to process 
it like a collection.


Now that we have a fully functional range, which can do all things desired, one 
can
then of course, pass this range without any change  to a collection based for … 
 e.g.

for v in (v1…v2).by(v3)   // optionally add other collection 
operators/filters/sorts here

(or in any other construct you might see fit)
   

This seems to be a reasonable alternative for

- the classical for ;; loop
-the collection-free for-loop  
 for v from v1 to v2 by v3

As you know, the latter is what I have been suggesting, 
but seemingly does not find much support,
(because I received very little reactions) 
making it doubtful if I will ever make a proposal for this for loop.
Anyone out there should I stil do that? 

When one does not further extend the range
with filters like sort etc. the compiler can still optimize 
a collection-in-between out of the way.
(Thank you Taras, für das Mitdenken. :o)


**   note that a half open range would in most cases be unnecessary 
  if  collection indexes started with 1 instead of 0, e.g. someArray[1…10] 
 (but it’s too late to change that.) 
 “the color of the first apple?”vs
 “the color of the zeroth (0) ???  apple?”? Silly isn’t? 

*** possible future numerical “native” types 


It could be that (at least) partly something similar has already been suggested.
but so much is here of this topic that i can’t see the wood for the trees, so 
to speak.


Your (all) opinions are appreciated. 

kind regards, mit freundlic

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

[Shawn Erickson via swift-evolution]

On Wed, Apr 6, 2016 at 1:29 PM Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't think you can fix counterintuitive behavior with guidance.
>
> (1..<199).striding(by: -2) is the first way I'd reach for to express
> 197, 195, ..., 3, 1
>
>
> I think a sensible specification would be that with a positive step size,
> the count starts from the lower bound, and with a negative one, it starts
> from the upper bound (inclusive or exclusive). Thus, the following examples
> should cover all the corner cases:
>
> (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]
>
> Lastly, if you want the positive stride reversed, you'd do just that:
>
> (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0]
>

I have always desired for a complete set of range variants like you
outlined above. I don't have current examples warranting a complete set but
I could easily see having to work on a data set that may be best done by
having a complete set of range variants so you don't need to transform the
data set to get it to work with the language you happen to be using. It
also better supports floating point ranges which may not have easy ways to
transform the data.

I also like the suggestion of how striding and reverse should work.

-Shawn
___
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

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 1:21 PM, Pyry Jahkola  wrote:
> 
>> Joe Groff wrote:
>> 
>> It's a judgment call. It's my feeling that in many cases, a generic 
>> parameter is constrained by at least one important protocol or base class 
>> that's worth calling out up front, so it's reasonable to allow things like 
>> 'func foo(x: C) -> C.Element' without banishing the 
>> 'Collection' constraint too far from the front of the declaration.
> 
> Fair enough. I think it would be clearer if all the constraints appeared in 
> one standard place (in the `where` clause).

That's definitely a reasonable position worth discussing.

-Joe
___
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 2:35 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Yes, but you can with warnings and fixits. 
> 
> * The compiler should issue a warning for any use of 
> 
> (n.. 
> with a fixit of "replace  (n.. whether n or m is known at compile time 
> 
> * If v cannot be known at compile time, I think the compiler should
> always prefer ... to ..<.
> 
> * The compiler should not allow
> 
> (n.. 
> where v is known at compile time to be a negative constant. There should 
> also be a runtime precondition that raises a fatal error should a negative 
> v be used with a half-open interval.
> 
> -- E

Following up to myself, this can easily be expanded to the other cases just
brought up by Xiaodi Wu

-- E


___
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 2:28 PM, Dave Abrahams via swift-evolution 
>  wrote:
> You if you need to represent `<..` intervals in scientific computing,
> that's a pretty compelling argument for supporting them.

>From a purely numerically aesthetic point of view, I'd much prefer ranges to 
>be 
openable and closable at both ends. 

My primary use-case has been teaching math using playgrounds but I'm sure 
there are lots of other real-world situations more specific to common numerical
method tasks.

-- E



___
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 2:17 PM, Dave Abrahams via swift-evolution 
>  wrote:
>> Guidance:
>> 
>> When using odd integer literals to produce an even number sequence,
>> prefer the `...` operator to the `..<` operator and change your ending
>> literal to an even number.
> 
> I don't think you can fix counterintuitive behavior with guidance.  
> 
> (1..<199).striding(by: -2) is the first way I'd reach for to express
> 197, 195, ..., 3, 1

Yes, but you can with warnings and fixits. 

* The compiler should issue a warning for any use of 

(n..___
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

[Ted F.A. van Gaalen via swift-evolution]

Hello Milos,
Good question
was thinking about this too.
that would imply the ‘by”value should/must always be an absolute value?
however (if it is a var) it cannot be guaranteed to be + or - 
that’s why I thought to leave it as is.
?
TedvG

> On 06.04.2016, at 22:18, Milos Rankovic  wrote:
> 
> 
>> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
>> (8.0…-3.14159).by(-0.0001) 
> 
> If the range does not assume `start >= end`, is it still necessary to also 
> indicate the traversal direction with the sign of the step (`-0.0001`)?
> 
> milos

___
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 Wed Apr 06 2016, Xiaodi Wu  wrote:

> On Wed, Apr 6, 2016 at 1:16 PM, Dave Abrahams  wrote:
>>
>> on Wed Apr 06 2016, Xiaodi Wu  wrote:
>>
>>> I think a lightbulb just went on for me:
>>>
>
>>> You're talking about expressing something in the vein of 
>>> `(0..<200).striding(by:
>>> -2)`, which has I'm sure many use cases, and which isn't straightforward to
>>> express with the current free function--I hadn't considered that.
>>>
>>> Meanwhile, I was trying to talk about something like `stride(from: 200, to: 
>>> 0,
>>> by: -2)`, which is easily expressed today but isn't straightforward at all 
>>> to
>>> preserve with only ranges. Clearly, given that this is what's on offer
>>> currently, someone who designed the language thinks (or thought) it's of 
>>> some
>>> use.
>>
>> That someone was me, and I explained that it wasn't an extremely
>> deeply-considered decision.
>
> Fair enough. Though your decision may not have been deeply considered,
> I wouldn't say it was an ill-considered one given that there wasn't
> (to my knowledge) any great clamor against it subsequently.
>
>>> In the absence of information as to which is more in demand, couldn't
>>> we have both?
>>
>> That's not how we make decisions about what should be in the language or
>> standard library.  We need to make choices based on (at least educated
>> guesses about) what people need, or we'll end up with a sprawling mess.
>
> Well, to elicit the kind of feedback that would help determine user
> needs, I would suggest that (when the eventually reconsidered syntax
> is proposed) this change should be highlighted explicitly as a feature
> removal. IMO, it wouldn't be otherwise immediately apparent from a
> quick glance that revising `stride(from: 0, to: 10, by: 1)` to
> `(0..<10).striding(by: 1)` necessarily entails deletion of backwards
> strides from upper bound to-and-not-through lower bound.
>
>>> If it must be a method on a range,
>>
>> It's not that it must be, but having such a method tends to reduce API
>> surface area.  We prefer methods to free functions.
>>
>>> then I would advocate for having what seems to be an utterly
>>> reasonable set of options for striding backwards:
>>>
>>> ```
>>> (0...200).striding(by: -2) // [a, b]
>>> (0..<200).striding(by: -2) // [a, b)
>>> (0<..200).striding(by: -2) // (a, b]
>>> ```
>>
>> And I'm trying to say that without a more compelling reason to introduce
>> `<..`, I don't want to do it.  I'd like to know that `<..` is useful
>> outside the domain of striding, for example.  Use-cases, anyone?
>
> Well, my use case (an actual one) is supremely mundane. I'm doing some
> scientific computing and I need to deal with numeric intervals. Some
> of them are closed, some of them are open at one end, and some at the
> other. 

You if you need to represent `<..` intervals in scientific computing,
that's a pretty compelling argument for supporting them.

> I'd like to be able to represent any of those as
> Intervals-which-are-now-Ranges. It makes sense to do so because the
> things I want to do with them, such as clamping and testing if some
> value is contained, are exactly what Intervals-now-Ranges provide.
> Looking around, it seems many other languages provide only what Swift
> currently does, but Perl does provide `..`, `..^`, `^..`, and `^..^`
> (which, brought over to Swift, would be `...`, `..<`, `<..`, and
> `<.<`).

Do we need fully-open ranges too?

>> Reasons we might not need it: the cases where it's important are much
>> more likely to be notionally continuous domains (e.g. floats), since you
>> can always write
>>
>> ((0+1)...200).striding(by: -2)
>>
>> and if you need the floating version there's always
>>
>>(0.0...200.0).striding(by: -2).lazy.filter { $0 != 0.0 }
>>
>> which probably optimizes down to the same code.
>>
>> One question that I *do* think we should answer, is whether the elements
>> of
>>
>> (0..<199).striding(by: -2)
>>
>> are even or odd.
>>
>>> On Wed, Apr 6, 2016 at 12:10 PM Dave Abrahams via swift-evolution
>>>  wrote:
>>>
>>> on Wed Apr 06 2016, Brent Royal-Gordon  
>>> wrote:
>>>
>>> >> For example, there are all kinds of other ways to slice this:
>>> >>
>>> >> stride(over: 0..<200, by: -2)
>>> >
>>> > This seems like a particularly good solution. The way I understand it
>>> > at least, it would allow ranges to always be ordered, with the only
>>> > difference being whether it went start-to-end or end-to-start,
>>> > determined by the stride's sign.
>>>
>>> This is no different in principle from
>>>
>>> (0..<200).striding(by: -2)
>>>
>>> Again, I wasn't trying to suggest any of the solutions listed there.
>>> The point I was making was that we don't have enough information to
>>> design more than
>>>
>>> (0..<200).striding(by: -2)
>>>
>>> > It would also avoid the need for additional range operators. The main
>>> > reason you would need `>..` is so you could say
>>> > `array.endIndex>

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

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu  wrote:
> Prohibiting StrideTo with floating-point ranges altogether would be
> distressing. IMO, it's plenty distressing that backwards
> floating-point StrideTo as it currently exists might go away.

I wouldn't suggest doing so. I'm just saying that for a half-open interval, 
there is no max value
so it makes no sense mathematically to have a first value and a negative step. 
You're not so restricted 
with:

* positive steps
* closed intervals

-- E

___
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

[Pyry Jahkola via swift-evolution]

> On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution 
>  wrote:
> 
> I don't think you can fix counterintuitive behavior with guidance.  
> 
> (1..<199).striding(by: -2) is the first way I'd reach for to express
> 197, 195, ..., 3, 1

I think a sensible specification would be that with a positive step size, the 
count starts from the lower bound, and with a negative one, it starts from the 
upper bound (inclusive or exclusive). Thus, the following examples should cover 
all the corner cases:

(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]

Lastly, if you want the positive stride reversed, you'd do just that:

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

— Pyry___
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

[Erica Sadun via swift-evolution]

On Apr 6, 2016, at 2:03 PM, Joe Groff via swift-evolution 
 wrote:
> 
>> 
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola  wrote:
>> 
>> Joe,
>> 
>> Just from your experience on this topic, is there any reason not to also 
>> move the primary constraints into the trailing `where` clause?
> It's a judgment call. It's my feeling that in many cases, a generic parameter 
> is constrained by at least one important protocol or base class that's worth 
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint 
> too far from the front of the declaration.

>From a reading point of view, it's always better to declare tokens before 
>using them. This groups them with the parameters (and the parameters in turn 
>may use the tokens), so the scope-specific vocabulary is all laid out in front.

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

[Shawn Erickson via swift-evolution]

I think the where clause should be moved to the end as you outlined an any
constraints beyond simple statements of conformance to a protocol or
superclass should only be allowed in the where clause. If someone desires
to state simple conformance/superclass for a generic parameter they should
be allowed to do so in either location.

On Wed, Apr 6, 2016 at 1:21 PM Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:

> Joe Groff wrote:
>
>
> It's a judgment call. It's my feeling that in many cases, a generic
> parameter is constrained by at least one important protocol or base class
> that's worth calling out up front, so it's reasonable to allow things like
> 'func foo(x: C) -> C.Element' without banishing the
> 'Collection' constraint too far from the front of the declaration.
>
>
> Fair enough. I think it would be clearer if all the constraints appeared
> in one standard place (in the `where` clause).
>
> — Pyry
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

> Joe Groff wrote:
> 
> It's a judgment call. It's my feeling that in many cases, a generic parameter 
> is constrained by at least one important protocol or base class that's worth 
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint 
> too far from the front of the declaration.

Fair enough. I think it would be clearer if all the constraints appeared in one 
standard place (in the `where` clause).

— Pyry___
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

[Milos Rankovic via swift-evolution]

Apologies, I inverted the operator there! This is, of course what I meant:

> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
> (8.0…-3.14159).by(-0.0001) 

If the range does not assume `start <= end`, is it still necessary to also 
indicate the traversal direction with the sign of the step (`-0.0001`)?

milos___
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 Wed Apr 06 2016, Erica Sadun  wrote:

>> On Apr 6, 2016, at 12:43 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed Apr 06 2016, Erica Sadun  wrote:
>> 
>
>>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution
>>> wrote:
>>>(0..<199).striding(by: -2)
>>> 
>>>are even or odd.
>>> 
>>> (0..<199).striding(by: -2): 0..<199 == 0...198 Even
>>> (1..<199).striding(by: -2): 1..<199 == 1...198 Even
>> 
>> I understand the logic that got you there, but I find it incredibly
>> counter-intuitive that striding by 2s over a range with odd endpoints
>> should produce even numbers... I can't imagine any way I'd be convinced
>> that was a good idea.
>
> Guidance:
>
> When using odd integer literals to produce an even number sequence,
> prefer the `...` operator to the `..<` operator and change your ending
> literal to an even number.

I don't think you can fix counterintuitive behavior with guidance.  

(1..<199).striding(by: -2) is the first way I'd reach for to express
197, 195, ..., 3, 1

>
>
> -- E
>
>> 
>>> (0..<198).striding(by: -2): 1..<198 == 0...197 Odd
>>> (1..<198).striding(by: -2): 1..<198 == 1...197 Odd
>>> 
>>> -- E
>>> 
>> 
>> -- 
>> Dave
>
> ___
> 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

[Milos Rankovic via swift-evolution]

> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
> (8.0…-3.14159).by(-0.0001) 

If the range does not assume `start >= end`, is it still necessary to also 
indicate the traversal direction with the sign of the step (`-0.0001`)?

milos___
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

[Xiaodi Wu via swift-evolution]

On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams  wrote:
>
> on Wed Apr 06 2016, Erica Sadun  wrote:
>
>> On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution
>>  wrote:
>> (0..<199).striding(by: -2)
>>
>> are even or odd.
>>
>> (0..<199).striding(by: -2): 0..<199 == 0...198 Even
>> (1..<199).striding(by: -2): 1..<199 == 1...198 Even
>
> I understand the logic that got you there, but I find it incredibly
> counter-intuitive that striding by 2s over a range with odd endpoints
> should produce even numbers... I can't imagine any way I'd be convinced
> that was a good idea.
>
>> (0..<198).striding(by: -2): 1..<198 == 0...197 Odd
>> (1..<198).striding(by: -2): 1..<198 == 1...197 Odd
>>

One other aspect of the counterintuitiveness is that
`(a..https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola  wrote:
> 
> Joe,
> 
> Just from your experience on this topic, is there any reason not to also move 
> the primary constraints into the trailing `where` clause?
> 
> So instead of what you wrote, we'd have it this way:
> 
> func foo(x: T, y: U) -> Result
>where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
> {
> }
> 
> …as well as:
> 
> struct Foo
>where T: Foo, U: Bar, T.Foo == U.Bar
> {
> }
> 
> Like I said earlier in this thread, I think this would also make the 
> `extension` syntax more uniform with types (by turning generic parameters 
> into strictly locally visible things):
> 
> extension Foo where U == Baz { // (Could've used X and Y here as 
> well.)
> // Now it's clear where the names T and U come from.
> var bazzes: [U] { return ... }
> }

It's a judgment call. It's my feeling that in many cases, a generic parameter 
is constrained by at least one important protocol or base class that's worth 
calling out up front, so it's reasonable to allow things like 'func foo(x: C) -> C.Element' without banishing the 'Collection' constraint 
too far from the front of the declaration.

-Joe
___
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

[Xiaodi Wu via swift-evolution]

On Wed, Apr 6, 2016 at 1:16 PM, Dave Abrahams  wrote:
>
> on Wed Apr 06 2016, Xiaodi Wu  wrote:
>
>> I think a lightbulb just went on for me:
>>
>> You're talking about expressing something in the vein of 
>> `(0..<200).striding(by:
>> -2)`, which has I'm sure many use cases, and which isn't straightforward to
>> express with the current free function--I hadn't considered that.
>>
>> Meanwhile, I was trying to talk about something like `stride(from: 200, to: 
>> 0,
>> by: -2)`, which is easily expressed today but isn't straightforward at all to
>> preserve with only ranges. Clearly, given that this is what's on offer
>> currently, someone who designed the language thinks (or thought) it's of some
>> use.
>
> That someone was me, and I explained that it wasn't an extremely
> deeply-considered decision.

Fair enough. Though your decision may not have been deeply considered,
I wouldn't say it was an ill-considered one given that there wasn't
(to my knowledge) any great clamor against it subsequently.


>> In the absence of information as to which is more in demand, couldn't
>> we have both?
>
> That's not how we make decisions about what should be in the language or
> standard library.  We need to make choices based on (at least educated
> guesses about) what people need, or we'll end up with a sprawling mess.

Well, to elicit the kind of feedback that would help determine user
needs, I would suggest that (when the eventually reconsidered syntax
is proposed) this change should be highlighted explicitly as a feature
removal. IMO, it wouldn't be otherwise immediately apparent from a
quick glance that revising `stride(from: 0, to: 10, by: 1)` to
`(0..<10).striding(by: 1)` necessarily entails deletion of backwards
strides from upper bound to-and-not-through lower bound.


>> If it must be a method on a range,
>
> It's not that it must be, but having such a method tends to reduce API
> surface area.  We prefer methods to free functions.
>
>> then I would advocate for having what seems to be an utterly
>> reasonable set of options for striding backwards:
>>
>> ```
>> (0...200).striding(by: -2) // [a, b]
>> (0..<200).striding(by: -2) // [a, b)
>> (0<..200).striding(by: -2) // (a, b]
>> ```
>
> And I'm trying to say that without a more compelling reason to introduce
> `<..`, I don't want to do it.  I'd like to know that `<..` is useful
> outside the domain of striding, for example.  Use-cases, anyone?

Well, my use case (an actual one) is supremely mundane. I'm doing some
scientific computing and I need to deal with numeric intervals. Some
of them are closed, some of them are open at one end, and some at the
other. I'd like to be able to represent any of those as
Intervals-which-are-now-Ranges. It makes sense to do so because the
things I want to do with them, such as clamping and testing if some
value is contained, are exactly what Intervals-now-Ranges provide.
Looking around, it seems many other languages provide only what Swift
currently does, but Perl does provide `..`, `..^`, `^..`, and `^..^`
(which, brought over to Swift, would be `...`, `..<`, `<..`, and
`<.<`).


> Reasons we might not need it: the cases where it's important are much
> more likely to be notionally continuous domains (e.g. floats), since you
> can always write
>
> ((0+1)...200).striding(by: -2)
>
> and if you need the floating version there's always
>
>(0.0...200.0).striding(by: -2).lazy.filter { $0 != 0.0 }
>
> which probably optimizes down to the same code.
>
> One question that I *do* think we should answer, is whether the elements
> of
>
> (0..<199).striding(by: -2)
>
> are even or odd.
>
>> On Wed, Apr 6, 2016 at 12:10 PM Dave Abrahams via swift-evolution
>>  wrote:
>>
>> on Wed Apr 06 2016, Brent Royal-Gordon  wrote:
>>
>> >> For example, there are all kinds of other ways to slice this:
>> >>
>> >> stride(over: 0..<200, by: -2)
>> >
>> > This seems like a particularly good solution. The way I understand it
>> > at least, it would allow ranges to always be ordered, with the only
>> > difference being whether it went start-to-end or end-to-start,
>> > determined by the stride's sign.
>>
>> This is no different in principle from
>>
>> (0..<200).striding(by: -2)
>>
>> Again, I wasn't trying to suggest any of the solutions listed there.
>> The point I was making was that we don't have enough information to
>> design more than
>>
>> (0..<200).striding(by: -2)
>>
>> > It would also avoid the need for additional range operators. The main
>> > reason you would need `>..` is so you could say
>> > `array.endIndex>..array.startIndex`, but by using the sign to decide
>> > which direction to stride over the range, you instead stride over
>> > `array.startIndex..> > have.
>> >
>> > Unfortunately, moving away from `stride(from:to/through:by:)` would
>> > kind of mess up an idea I've been developing for providing an
>> > "induction sequence" t

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

[Ted F.A. van Gaalen via swift-evolution]

Hi Erica, Dave

Based on what I’ve (not all) read under this topic: 

I’d suggest a more complete approach:

Ranges should support:  (as yet not implemented) 

- All numerical data types (Double, Float, Int, Money***, Decimal*** ) 
- An arbitrary increment or decrement value.
- Working in the complete  - + numerical range
- Allow traversing in both   - + directions.



The basics:

(v1…v2).by(v3) // this still is readable. and can be optimized by the 
compiler (predictable sequence)

Rules:

v1, v2, v3  are any numerical type scalar type  
v1, v2, v3  must have the same numerical type.
v1 >  v2:   is allowed and correctly evaluated.  e.g. 
(8.0…-3.14159).by(-0.0001) 


The  ..<  half open operator is no longer allowed.   write e.g.   
0...ar.count - 1

"by(…)”  is obligatory with floating point range.

   the default “by(…)” value of 1 makes sense only with integer ranges.


valid examples:
(5…9)// 5 6 7 8 9 Integer range without “by” 
defaults to 1 as increment value.
(1...10).by(2) // 1 3 5 7 9.
(2...10).by(2) // 2 4 6 8 10.
(4…-4).by(2) // 4  2 0 -2 -4 .// runs backwards
(30..-10).by(-2)// 30 28 26 24 22 ….. -10.
(10...0).by(-3)  // 10 7 4 1. 

(12…-10) // is valid, but returns empty because default 
increment value = 1

(12.0…-12.0).by(-1.5)   // 12.0  10.5  9.0….  // of course with 
float imprecision
   
   

   invalid examples:

   (23.0..<60.5).by(0.5) // half open ranges are no  longer allowed ** 
  (23.0…60.5) // “ by"  is obligatory with floats.
  (14...8).by(0.5)//  v1 v2 and v3 don’t have the same 
numerical type 


Half open ranges make no real sense (are not really useful) with floating point 
values.
and no sense at all with e.g (12..<-1)  afaics 


At least for float iterations the increment value should not each time be 
accumulated like
v1 += v3;  v1 += v3;  v1 += v3;  ….   // causes float 
number drift.
but be freshly multiplied with each iteration, e.g. by using an internal 
iteration counter
like so:

v1 = v3 * i++;   v1 = v3 * i++;   v1 = v3 * i++;….

for reasons of precision.

If one has worked with floating point data more often
awareness of its precision limitations become a second nature conscience. 
E.g. it is perfectly acceptable and known (also in classical for-loops) that
(0.0…1.0).by(0.1) is not guaranteed to reach the humanly expected value of 1.0.
This is normal. Due to the nature of what mostly is done in the
floating point numbers domain, this does not often cause a problem
(e.g like working with a slide ruler) 
if it is important to reach the “expected end” then one could
-add an epsilon value like so (v1…v2 + 0.1) 
-generate the desired float sequence within an integer loop.


The above “range” (imho) improvement makes the 
stride.. function/keyword completely unnecessary.

Due to its ability to process reversed ranges as is, 
the .reverse() is optional (no longer necessary in most cases,
allowing the compiler to optimize without having to process 
it like a collection.


Now that we have a fully functional range, which can do all things desired, one 
can
then of course, pass this range without any change  to a collection based for … 
 e.g.

for v in (v1…v2).by(v3)   // optionally add other collection 
operators/filters/sorts here

(or in any other construct you might see fit)
   

This seems to be a reasonable alternative for

- the classical for ;; loop
-the collection-free for-loop  
 for v from v1 to v2 by v3

As you know, the latter is what I have been suggesting, 
but seemingly does not find much support,
(because I received very little reactions) 
making it doubtful if I will ever make a proposal for this for loop.
Anyone out there should I stil do that? 

When one does not further extend the range
with filters like sort etc. the compiler can still optimize 
a collection-in-between out of the way.
(Thank you Taras, für das Mitdenken. :o)


**   note that a half open range would in most cases be unnecessary 
  if  collection indexes started with 1 instead of 0, e.g. someArray[1…10] 
 (but it’s too late to change that.) 
 “the color of the first apple?”vs
 “the color of the zeroth (0) ???  apple?”? Silly isn’t? 

*** possible future numerical “native” types 


It could be that (at least) partly something similar has already been suggested.
but so much is here of this topic that i can’t see the wood for the trees, so 
to speak.


Your (all) opinions are appreciated. 

kind regards, mit freundlichen Grüssen, Met vriendelijke groeten, 
Sigh, why do we Dutch always have to speak the languages of the bigger 
countries :o) 
TedvG

> on Wed Apr 06 2016, Erica Sadun  

Re: [swift-evolution] Generic Alaises

[Milos Rankovic via swift-evolution]

Chris Lattner has a proposal under review 

 on this topic. 

milos

> On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
>  wrote:
> 
> This was inspired from the topic about moving where clauses out of parameter 
> lists.
> 
> Certain generics get very long winded, I was wondering if we could create 
> some sort of alias for generics.
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> could be shared across functions like so:
> 
> genericalias SequencesWithSameElements =   SequenceType where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element>
> 
> func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
> func ==  (lhs: T, _ rhs: U) -> Bool
> ___
> 
> James⎥
> 
> ja...@supmenow.com ⎥supmenow.com 
> 
> Sup
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> London
> 
> 
> EC2A 1AF 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Milos Rankovic via swift-evolution]

> For example, this Standard Library function:
> 
> public func + <
> C : RangeReplaceableCollectionType,
> S : SequenceType
> where S.Generator.Element == C.Generator.Element
> > (lhs: C, rhs: S) -> C
> 
> would become:
> 
> public func + (lhs: C, rhs: S) -> C where <
> C : RangeReplaceableCollectionType
> C : SequenceType
> S.Generator.Element == C.Generator.Element
> >
> 

As for structs, this Standard Library struct:

public struct FlattenBidirectionalCollection  
: CollectionType { … }

… could become:

public struct FlattenBidirectionalCollection : CollectionType 
where <
 Base : CollectionType
 Base.Generator.Element : CollectionType
 Base.Index : BidirectionalIndexType
 Base.Generator.Element.Index : BidirectionalIndexType
> { … }

milos___
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

[Pyry Jahkola via swift-evolution]

Joe,

Just from your experience on this topic, is there any reason not to also move 
the primary constraints into the trailing `where` clause?

So instead of what you wrote, we'd have it this way:

func foo(x: T, y: U) -> Result
   where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
{
}

…as well as:

struct Foo
   where T: Foo, U: Bar, T.Foo == U.Bar
{
}

Like I said earlier in this thread, I think this would also make the 
`extension` syntax more uniform with types (by turning generic parameters into 
strictly locally visible things):

extension Foo where U == Baz { // (Could've used X and Y here as 
well.)
// Now it's clear where the names T and U come from.
var bazzes: [U] { return ... }
}

— Pyry

> I think this is a good idea, though I would put the `where` clause after the 
> function signature:
> 
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
> 
> As others noted, it's also appealing to do this for type declarations too:
> 
> struct Foo
>where T.Foo == U.Bar
> {
> }
> 
> and that gives a consistent feeling with extensions and protocol declarations.


___
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

[plx via swift-evolution]

I don’t see much value in moving them out of the angle brackets but preserving 
the position; consider:

  // status-quo:
  func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool
  
  // as-per proposal:
  func anyCommonElements 
where 
T.Generator.Element: Equatable, 
T.Generator.Element == U.Generator.Element
(lhs: T, _ rhs: U) -> Bool

…not very different! Or, if you want it with fewer lines:

  // status-quo:
  func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool
  
  // as-per proposal:
  func anyCommonElements 
where T.Generator.Element: Equatable, T.Generator.Element == 
U.Generator.Element
(lhs: T, _ rhs: U) -> Bool

…still not very different!

Moving the `where` to come after “everything else" seems like an improvement 
for functions:

  func anyCommonElements (lhs: T, _ rhs: U) 
-> Bool
where 
T.Generator.Element: Equatable, 
T.Generator.Element == U.Generator.Element { 
  // body here...
}

…and presumably-also for type declarations:

  class SomeClass : BaseClass, SomeProtocol, AnotherProtocol
where
A.Something == SomethingElse,
B.Input == C.Output {

  }

..,but would take some getting-used-to.

Losing the ability to write `:` constraints inline in the brackets seems a 
non-starter, but perhaps constraints within the brackets could be limited to 
`:` constraints?

> On Apr 6, 2016, at 1:30 PM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?
> 
> ~Robert Widmann
> ___
> 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] Generic Alaises

[James Campbell via swift-evolution]

This was inspired from the topic about moving where clauses out of
parameter lists.

Certain generics get very long winded, I was wondering if we could create
some sort of alias for generics.

func anyCommonElements 
(lhs: T, _ rhs: U) -> Bool

could be shared across functions like so:

genericalias SequencesWithSameElements =  

func anyCommonElements  (lhs: T, _ rhs: U) ->
Bool
func ==  (lhs: T, _ rhs: U) -> Bool

*___*

*James⎥*

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

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *
___
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

[Joe Groff via swift-evolution]

> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?

I think this is a good idea, though I would put the `where` clause after the 
function signature:

func foo(x: T, y: U) -> Result
where T.Foo == U.Bar /*, etc. */
{
}

 As others noted, it's also appealing to do this for type declarations too:

struct Foo
where T.Foo == U.Bar
{
}

and that gives a consistent feeling with extensions and protocol declarations.

-Joe
___
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

[Developer via swift-evolution]

Even better.  +1.

~Robert Widmann

2016/04/06 14:35、Pyry Jahkola via swift-evolution  
のメッセージ:

>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>>  wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.
> 
> +1 already!
> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
> 
> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
> 
> ― Pyry
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Milos Rankovic via swift-evolution]

> On 6 Apr 2016, at 19:48, Sean Heber  wrote:
> 
> This almost seems like it could work so that it didn't even need the 
> bracketed parts to be able to figure out the types:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.Generator.Element
> {}
> 

But if the brackets are kept, we may be able to do away with commas? For 
example, this Standard Library function:

public func + <
C : RangeReplaceableCollectionType,
S : SequenceType
where S.Generator.Element == C.Generator.Element
> (lhs: C, rhs: S) -> C

would become:

public func + (lhs: C, rhs: S) -> C where <
C : RangeReplaceableCollectionType
C : SequenceType
S.Generator.Element == C.Generator.Element
>
 
Brackets may also be needed for the api view of the library.

milos

___
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

[Sean Heber via swift-evolution]

I would think it’d just be unconstrained generic parameters - same as this is 
now:

func f(lhs: A, _ rhs: B) {}

However I can see how it’d certainly be potentially too confusing. It might be 
worthwhile to retain the brackets, but require type restrictions to be moved to 
the trailing “where” so that it keeps the <> part as short as possible, so this 
would be an error:

func f(lhs: A, _ rhs: B) -> Bool {}

And would have to be written:

func f(lhs: A, _ rhs: B) -> Bool where A: SequenceType, B: Equatable {}

Maybe? That’s a bit longer, though. Maybe it’s not worth changing that aspect 
of it. I like moving “where” to the end, though.

l8r
Sean


> On Apr 6, 2016, at 1:53 PM, Timothy Wood  wrote:
> 
> 
>> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
>> This almost seems like it could work so that it didn't even need the 
>> bracketed parts to be able to figure out the types:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>>   T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {}
>> 
> 
> ... though if there are no type constraints, this would be ambiguous:
> 
>   // If there are no know types T and R in scope, is this an error or are 
> T and R assumed to be unconstrained generic parameters?
>   func f(arg: T) -> R
> 
> -tim
> 

___
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

[Juan Ignacio Laube via swift-evolution]

+1. I like the idea of seeing the function signature first, then the 
constraints.


> On Apr 6, 2016, at 3:47 PM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
> 
> This is an excellent idea: +1!
> 
> If `where` is left on a previous line, it would also appear more in line with 
> `throws`:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
> T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> 
> 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

With `where` at the end, the Standard Library function:

public func != <
A : Equatable, 
B : Equatable, 
C : Equatable, 
D : Equatable, 
E : Equatable, 
F : Equatable
> (lhs: (A, B, C, D, E, F), rhs: (A, B, C, D, E, F)) -> Bool

becomes:

public func != (lhs: (A, B, C, D, E, F), rhs: (A, B, C, D, E, F)) -> 
Bool where <
A : Equatable,
B : Equatable,
C : Equatable,
D : Equatable,
E : Equatable,
F : Equatable
>
milos

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>  wrote:
> 
>> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> If you've ever gotten to the point where you have a sufficiently generic 
>> interface to a thing and you need to constrain it, possibly in an extension, 
>> maybe for a generic free function or operator, you know what a pain the 
>> syntax can be for these kinds of operations.
> 
> +1 already!
> 
>> Or, if you're feeling ambitious, even
>> 
>> func anyCommonElements 
>> where T : SequenceType, U : SequenceType,
>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>> (lhs: T, _ rhs: U) -> Bool
> 
> I would actually move them as far as after everything else, and right before 
> the definition body. For the above function that would mean:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> That would make the definition look closer to what the call site looks like.
> 
> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
> 
> — Pyry
> ___
> 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 12:43 PM, Dave Abrahams  wrote:
> 
> 
> on Wed Apr 06 2016, Erica Sadun  wrote:
> 
>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution
>> wrote:
>>(0..<199).striding(by: -2)
>> 
>>are even or odd.
>> 
>> (0..<199).striding(by: -2): 0..<199 == 0...198 Even
>> (1..<199).striding(by: -2): 1..<199 == 1...198 Even
> 
> I understand the logic that got you there, but I find it incredibly
> counter-intuitive that striding by 2s over a range with odd endpoints
> should produce even numbers... I can't imagine any way I'd be convinced
> that was a good idea.

Guidance:

When using odd integer literals to produce an even number sequence,
prefer the `...` operator to the `..<` operator and change your ending
literal to an even number.

-- E


> 
>> (0..<198).striding(by: -2): 1..<198 == 0...197 Odd
>> (1..<198).striding(by: -2): 1..<198 == 1...197 Odd
>> 
>> -- E
>> 
> 
> -- 
> Dave

___
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

[Taras Zakharko via swift-evolution]

A big +1 to this notation. 


> On 06 Apr 2016, at 20:47, Milos Rankovic via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
> 
> This is an excellent idea: +1!
> 
> If `where` is left on a previous line, it would also appear more in line with 
> `throws`:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
> T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> 
> 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Pyry Jahkola via swift-evolution]

> This almost seems like it could work so that it didn't even need the 
> bracketed parts to be able to figure out the types:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.Generator.Element
> {}

I'd still keep the generic arguments listed there in the brackets if only for 
the following reasons:

1. The new names get introduced (in `<...>`) before their first use. So if you 
happened to name one of them `String`, it would be clear that you didn't mean 
`Swift.String`.

2. It's been sometimes wished that you could explicitly specify which 
specialisation you want to use, e.g. when passing a function into a handler 
(e.g. `let operation = anyCommonElements<[Int], [Int]>(_:_:)`).

3. How would you otherwise mention a generic type if there were no constraints 
for it? I think the suggested form:

extension Array {
// no constraints needed (not for T above, not for U below)
func map(transform: T -> U) -> Array { ... }
}

reads better than this:

extension Array {
// Wait what, where did U come from?
func map(transform: T -> U) -> Array { ... }
}

— Pyry___
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

[Erica Sadun via swift-evolution]

> On Apr 6, 2016, at 12:30 PM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> Thoughts?

+1.

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

[Timothy Wood via swift-evolution]

> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution 
>  wrote:
> 
> This almost seems like it could work so that it didn't even need the 
> bracketed parts to be able to figure out the types:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.Generator.Element
> {}
> 

... though if there are no type constraints, this would be ambiguous:

// If there are no know types T and R in scope, is this an error or are 
T and R assumed to be unconstrained generic parameters?
func f(arg: T) -> R

-tim

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

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Daniel Dunbar via swift-evolution]

> On Apr 6, 2016, at 11:11 AM, Max Howell  wrote:
> 
>> I don't see that information in the man page (also, I am not familiar enough 
>> with pkg-config to know how results described in that man page translate to 
>> other systems).
>> 
>> Specifically, that man page does not seem to document where on disk the .pc 
>> files live. How are we going to know that?
>> 
>> For example, one on random VM I have lying about I see .pc files here:
>> --
>> /# find / -name \*.pc | xargs dirname | sort | uniq
>> /usr/lib/pkgconfig
>> /usr/lib/x86_64-linux-gnu/pkgconfig
>> /usr/lib/x86_64-linux-gnu/pkgconfig/mit-krb5
>> /usr/share/pkgconfig
>> --
>> and the pkg-config tool appears to be able to find results from all of 
>> those. How would we know those directory names if we don't have a dependency 
>> on the actual tool?
> 
> There is a config file and an environment variable.
> 
> Do you need me to document them completely so that we can move forward with 
> this?

No, not at all, I think the proposal makes complete sense and should be moved 
along.

Nevertheless, I still want to understand how it will work... I might be missing 
some information from the man page but I just don't see where this is 
described. It *looks* to me like the default search list is hard coded into the 
tool.

 - Daniel___
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

[Sean Heber via swift-evolution]

This almost seems like it could work so that it didn't even need the bracketed 
parts to be able to figure out the types:

func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
T : SequenceType,
U : SequenceType,
T.Generator.Element: Equatable,
T.Generator.Element == U.Generator.Element
{}

.. which would address my concerns about distance from names to params, too!

l8r
Sean



> On Apr 6, 2016, at 1:47 PM, Milos Rankovic via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>>  wrote:
>> 
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>>   U : SequenceType,
>>   T.Generator.Element: Equatable,
>>   T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>> 
> 
> This is an excellent idea: +1!
> 
> If `where` is left on a previous line, it would also appear more in line with 
> `throws`:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
> T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 
> 
> 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] [Pitch] Moving where Clauses Out Of Parameter Lists

[Milos Rankovic via swift-evolution]

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
>   U : SequenceType,
>   T.Generator.Element: Equatable,
>   T.Generator.Element == U.Generator.Element
> {
> ...
> }
> 

This is an excellent idea: +1!

If `where` is left on a previous line, it would also appear more in line with 
`throws`:

func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
T : SequenceType,
U : SequenceType,
T.Generator.Element: Equatable,
T.Generator.Element == U.Generator.Element
{
...
}


milos___
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 Wed Apr 06 2016, Erica Sadun  wrote:

> On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution
>  wrote:
> (0..<199).striding(by: -2)
>
> are even or odd.
>
> (0..<199).striding(by: -2): 0..<199 == 0...198 Even
> (1..<199).striding(by: -2): 1..<199 == 1...198 Even

I understand the logic that got you there, but I find it incredibly
counter-intuitive that striding by 2s over a range with odd endpoints
should produce even numbers... I can't imagine any way I'd be convinced
that was a good idea.

> (0..<198).striding(by: -2): 1..<198 == 0...197 Odd
> (1..<198).striding(by: -2): 1..<198 == 1...197 Odd
>
> -- E
>

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

[Pyry Jahkola via swift-evolution]

> The same would work for generic types  too:
> 
> public struct Dictionary
> where Key : Hashable
> {
>...
> }

And I'm not sure if people feel the same as me, but I haven't been happy with 
the current way generic arguments (such as Key and Value above) magically 
appear in type extensions but are inaccessible from anywhere else and can't be 
made public (`public typealias Key = Key` is an error).

The above syntax would make it possible to use whatever identifiers locally so 
that it's clear what they are:

extension Dictionary
// (unclear if `where K : Hashable` should be repeated here, though)
{
...
}

extension Array
where T : Comparable
{
...
}

extension Array
where T == String
{
...
}

etc.

— Pyry___
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

[Sean Heber via swift-evolution]

*grabs paintbrush*

Something that has always bothered me about the generic syntax for functions is 
how far the function’s name is from its parameters. There are probably reasons 
why the following might not work, but it could address my desire to keep the 
name of the thing close to the names of the inputs:

func 
where T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
anyCommonElements(lhs: T, _ rhs: U) -> Bool {
}

I haven't given this tons of thought, but this seemed like a good a thread as 
any to mention my concern about the distance of the name from the parameters. :)

l8r
Sean



> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool



> On Apr 6, 2016, at 1:30 PM, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.  For example, the Swift book 
> implements this example to motivate where clauses
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> This is noisy and uncomfortable to my eyes, and almost impossible to align 
> correctly.  Per a short discussion on Twitter with Joe Groff and Erica Sadun, 
> I'd like so see what the community feels about moving the where clause out of 
> the angle brackets.  So that example becomes
> 
> func anyCommonElements 
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
> 
> Thoughts?
> 
> ~Robert Widmann
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Shawn Erickson via swift-evolution]

On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:

> On 06 Apr 2016, at 21:30, Developer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an
> extension, maybe for a generic free function or operator, you know what a
> pain the syntax can be for these kinds of operations.
>
>
> +1 already!
>
> Or, if you're feeling ambitious, even
>
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
>
>
> I would actually move them as far as after everything else, and right
> before the definition body. For the above function that would mean:
>
> func anyCommonElements*(lhs: T, _ rhs: U) -> Bool*
> *where T : SequenceType,*
>
> *  U : SequenceType,  T.Generator.Element: Equatable,*
>
> *  T.Generator.Element == U.Generator.Element*
> {
> ...
> }
>
> That would make the definition look closer to what the call site looks
> like.
>
> The same would work for generic types  too:
>
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
>

I very much like this suggestion.
___
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 12:30 PM, Dave Abrahams via swift-evolution 
>  wrote:
> on Wed Apr 06 2016, Stephen Canon  wrote:
>> For the (0..<199) case, Erica’s assessment 
> 
> which is...?

https://gist.github.com/erica/786ab9703f699db1301be65510e7da03 


-- E

___
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

[Milos Rankovic via swift-evolution]

> On 6 Apr 2016, at 19:16, Dave Abrahams via swift-evolution 
>  wrote:
> 
> We prefer methods to free functions.

However, `(from:to:by)` need not be a free function, it could be a sequence 
initialiser:

Walk(from: 200, to: 0, by: 2)

or:

Steps(from: 200, to: 0, by: 2)

or something along those lines...

milos___
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

[Pyry Jahkola via swift-evolution]

> On 06 Apr 2016, at 21:30, Developer via swift-evolution 
>  wrote:
> 
> If you've ever gotten to the point where you have a sufficiently generic 
> interface to a thing and you need to constrain it, possibly in an extension, 
> maybe for a generic free function or operator, you know what a pain the 
> syntax can be for these kinds of operations.

+1 already!

> Or, if you're feeling ambitious, even
> 
> func anyCommonElements 
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool

I would actually move them as far as after everything else, and right before 
the definition body. For the above function that would mean:

func anyCommonElements(lhs: T, _ rhs: U) -> Bool
where T : SequenceType,
  U : SequenceType,
  T.Generator.Element: Equatable,
  T.Generator.Element == U.Generator.Element
{
...
}

That would make the definition look closer to what the call site looks like.

The same would work for generic types  too:

public struct Dictionary
where Key : Hashable
{
   ...
}

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

Re: [swift-evolution] deployment targets and frameworks

[Douglas Gregor via swift-evolution]

> On Apr 6, 2016, at 11:04 AM, Jonathan Tang  wrote:
> 
> 
> 
> On Wed, Apr 6, 2016 at 9:58 AM, Douglas Gregor via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Apr 5, 2016, at 4:04 PM, Drew Crawford > > wrote:
>> 
>> 
>>> On Apr 5, 2016, at 12:06 PM, Douglas Gregor >> > wrote:
>>> 
>>> I would not want this to be implicit behavior: it should be recorded in the 
>>> source with, e.g.,
>>> 
>>> @availability(iOS: 9.3) import YourCustomFramework
>>> 
>>> so that it is clear that the imported declarations are only available on 
>>> iOS 9.3 or newer.
>>> 
>>> - Doug
>> 
>> Would you promote using this syntax for the Apple frameworks as well?
> 
> 
>> A major goal for me is syntax consistency between Apple's and third-party 
>> frameworks.  That way the knowledge of how to use one transfers to the 
>> other, and we ensure people with fresh ideas about how to build frameworks 
>> are not burdened with educating application developers about "novel" import 
>> syntax.
> 
> Apple frameworks tend to have ail their various classes and other APIs 
> annotated with availability attributes, so I wouldn’t expect to need this 
> import syntax for any of those. Really, this syntax is a shorthand for “treat 
> the imported library as if the author had put this availability annotation on 
> all of its public APIs”. If your goal is consistency between Apple frameworks 
> and other frameworks, I don’t think this is the way to go.
> 
> 
> 
> Does this mean that the recommended best practice for framework authors is to 
> set the deployment target low and then add an availability attribute for 
> every public symbol? 

Every public symbol that needs it, sure. Fortunately, Swift tells you when you 
get it wrong.

- Doug


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