Re: [swift-evolution] [Idea] Generic associated types

[Xiaodi Wu via swift-evolution]

On Sun, Mar 12, 2017 at 1:39 AM, Karl Wagner  wrote:

>
> On 12 Mar 2017, at 08:21, Xiaodi Wu  wrote:
>
> Sorry, I'm confused. The following works:
>
> ```
> protocol Promise {
>   associatedtype Result
> }
>
> protocol Scanner {
>   associatedtype ScannerPromise : Promise
>   func frobnicate(_: T) -> ScannerPromise
> where ScannerPromise.Result == T
> }
> ```
>
> Why does it matter if `ScannerPromise` is generic or not?
>
>
> That’s some pretty strange syntax. I admit I didn’t even try that.
> ScannerPromise would necessarily have to be generic in this context,
> because I want to bind one of its associated types to a generic parameter
> from a function. There is no way a non-generic type could do that.
>
> That said, even though the compiler accepts your code, it doesn’t seem to
> actually work:
>
> protocol Promise {
>   associatedtype Result
>   func await() -> Result
> }
>
> protocol Scanner {
>   associatedtype ScannerPromise : Promise
>   func frobnicate(_: T) -> ScannerPromise
> where ScannerPromise.Result == T
> }
>
> func use(_ s: S, _ t: T) -> T {
> return s.frobnicate(t).await()
> }
>
>
>
> 3.0.2: Segfault
>
> 3.1:
>
> error: repl.swift:13:14: error: cannot invoke 'frobnicate' with an
> argument list of type '(T)'
> return s.frobnicate(t).await()
>  ^
>
> repl.swift:13:14: note: expected an argument list of type '(T)'
> return s.frobnicate(t).await()
>

That's because your `T` in `use` has no relationship with your `T` in
`protocol Scanner`; you just happen to have chosen the same letter of the
alphabet. This becomes clear if you rename:

```

func use(_ s: S, _ t: U) -> U {

  return s.frobnicate(t).await()

}


*// cannot invoke 'frobnicate' with an argument list of type '(U)'*

*// expected an argument list of type '(T)'*
```

However, this works:

```

func use(_ s: S, _ t: T) -> T

  where S.ScannerPromise.Result == T {

  return s.frobnicate(t).await()

}
```

...or just this:

```

func use(

  _ s: S, _ t: S.ScannerPromise.Result

) -> S.ScannerPromise.Result {

  return s.frobnicate(t).await()

}
```

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

Re: [swift-evolution] [Idea] Generic associated types

[Karl Wagner via swift-evolution]

> On 12 Mar 2017, at 08:21, Xiaodi Wu  wrote:
> 
> Sorry, I'm confused. The following works:
> 
> ```
> protocol Promise {
>   associatedtype Result
> }
> 
> protocol Scanner {
>   associatedtype ScannerPromise : Promise
>   func frobnicate(_: T) -> ScannerPromise
> where ScannerPromise.Result == T
> }
> ```
> 
> Why does it matter if `ScannerPromise` is generic or not?
> 

That’s some pretty strange syntax. I admit I didn’t even try that. 
ScannerPromise would necessarily have to be generic in this context, because I 
want to bind one of its associated types to a generic parameter from a 
function. There is no way a non-generic type could do that.

That said, even though the compiler accepts your code, it doesn’t seem to 
actually work:

protocol Promise {
  associatedtype Result
  func await() -> Result
}

protocol Scanner {
  associatedtype ScannerPromise : Promise
  func frobnicate(_: T) -> ScannerPromise
where ScannerPromise.Result == T
}

func use(_ s: S, _ t: T) -> T {
return s.frobnicate(t).await()
}


3.0.2: Segfault

3.1:

error: repl.swift:13:14: error: cannot invoke 'frobnicate' with an argument 
list of type '(T)'
return s.frobnicate(t).await()
 ^

repl.swift:13:14: note: expected an argument list of type '(T)'
return s.frobnicate(t).await()

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

Re: [swift-evolution] [Idea] Generic associated types

[Xiaodi Wu via swift-evolution]

Sorry, I'm confused. The following works:

```

protocol Promise {

  associatedtype Result

}


protocol Scanner {

  associatedtype ScannerPromise : Promise

  func frobnicate(_: T) -> ScannerPromise

where ScannerPromise.Result == T

}
```

Why does it matter if `ScannerPromise` is generic or not?


On Sat, Mar 11, 2017 at 11:55 PM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 12 Mar 2017, at 06:51, Austin Zheng  wrote:
>
> I think you want higher-kinded types. https://github.com/
> apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types
>
> Best,
> Austin
>
> On Mar 11, 2017, at 9:49 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have a model like this:
>
> protocol Promise {
> associatedtype Result
> }
>
> protocol Scanner {
> associatedtype ScanPromise: Promise
>
> func promiseScan(from: Offset, until: (Offset, Item) -> T?) ->
> ScanPromise // where Result == T?
> }
>
>
> The thing that I’m trying to express is: whichever type implements the
> associated type ‘ScanPromise’ must be generic, and that parameter must be
> its result (i.e. something it got as a result of calling the “until”
> closure).
>
> Even with SE-0142, this kind of constraint would not be possible. What I
> would like to write is something like this:
>
> protocol Promise {
> associatedtype Result
> }
>
> protocol Scanner {
> associatedtype ScanPromise: Promise // now generic. [SE-0142]:
> where Result == T
>
> func promiseScan(from: Offset, until: (Offset, Item) -> T?) ->
> ScanPromise
> }
>
> Thoughts?
>
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> Not necessarily. Higher-kinded types (IIUC) are per-instance - e.g. every
> instance of a Collection could have a unique type of Index.
>
> I want to constrain a return value, whose type is an associated type,
> based on a generic parameter to the function. SE-0142 only allows
> constraining entire associated types, and allows no interaction with
> per-function generic parameters.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Generic associated types

[Karl Wagner via swift-evolution]

> On 12 Mar 2017, at 06:51, Austin Zheng  wrote:
> 
> I think you want higher-kinded types. 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types
>  
> 
> 
> Best,
> Austin
> 
>> On Mar 11, 2017, at 9:49 PM, Karl Wagner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I have a model like this:
>> 
>> protocol Promise {
>> associatedtype Result
>> }
>> 
>> protocol Scanner {
>> associatedtype ScanPromise: Promise
>> 
>> func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> 
>> ScanPromise // where Result == T?
>> }
>> 
>> The thing that I’m trying to express is: whichever type implements the 
>> associated type ‘ScanPromise’ must be generic, and that parameter must be 
>> its result (i.e. something it got as a result of calling the “until” 
>> closure).
>> 
>> Even with SE-0142, this kind of constraint would not be possible. What I 
>> would like to write is something like this:
>> 
>> protocol Promise {
>> associatedtype Result
>> }
>> 
>> protocol Scanner {
>> associatedtype ScanPromise: Promise // now generic. [SE-0142]: where 
>> Result == T
>> 
>> func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> 
>> ScanPromise
>> }
>> 
>> Thoughts?
>> 
>> - Karl
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 


Not necessarily. Higher-kinded types (IIUC) are per-instance - e.g. every 
instance of a Collection could have a unique type of Index.

I want to constrain a return value, whose type is an associated type, based on 
a generic parameter to the function. SE-0142 only allows constraining entire 
associated types, and allows no interaction with per-function generic 
parameters.

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

Re: [swift-evolution] [Idea] Generic associated types

[Austin Zheng via swift-evolution]

I think you want higher-kinded types. 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types
 


Best,
Austin

> On Mar 11, 2017, at 9:49 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> I have a model like this:
> 
> protocol Promise {
> associatedtype Result
> }
> 
> protocol Scanner {
> associatedtype ScanPromise: Promise
> 
> func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> 
> ScanPromise // where Result == T?
> }
> 
> The thing that I’m trying to express is: whichever type implements the 
> associated type ‘ScanPromise’ must be generic, and that parameter must be its 
> result (i.e. something it got as a result of calling the “until” closure).
> 
> Even with SE-0142, this kind of constraint would not be possible. What I 
> would like to write is something like this:
> 
> protocol Promise {
> associatedtype Result
> }
> 
> protocol Scanner {
> associatedtype ScanPromise: Promise // now generic. [SE-0142]: where 
> Result == T
> 
> func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> 
> ScanPromise
> }
> 
> Thoughts?
> 
> - Karl
> ___
> 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] [Idea] Generic associated types

[Karl Wagner via swift-evolution]

I have a model like this:

protocol Promise {
associatedtype Result
}

protocol Scanner {
associatedtype ScanPromise: Promise

func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> 
ScanPromise // where Result == T?
}

The thing that I’m trying to express is: whichever type implements the 
associated type ‘ScanPromise’ must be generic, and that parameter must be its 
result (i.e. something it got as a result of calling the “until” closure).

Even with SE-0142, this kind of constraint would not be possible. What I would 
like to write is something like this:

protocol Promise {
associatedtype Result
}

protocol Scanner {
associatedtype ScanPromise: Promise // now generic. [SE-0142]: where 
Result == T

func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> 
ScanPromise
}

Thoughts?

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

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

[Chris Lattner via swift-evolution]

> On Mar 10, 2017, at 9:33 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> Is this a feature or a bug?

Low priority bug IMO.

-Chris


> class Foo {
> let bar: Int
> init?(someConditionBasedOnInputData: Bool) {
> var localBar: Int = 0
> defer {
> bar = localBar //Cannot assign to property: 'bar' is a 'let' 
> constant
> }
> if someConditionBasedOnInputData {
> return nil
> }
> }
> }
> It’d be handy to be able to do the assignment upfront in a defer block in 
> cases where there’s both a bunch of validation to do on the input data, and 
> no harm from assigning the interim values to the final values when you’re 
> about to return nil anyway.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Ricardo Parada via swift-evolution]

I read Haravikk's proposal a second time. I think I see the advantage of being 
able to use it with other types besides array. 

I also found disambiguating with the trailing comma to be intuitive. On the 
other hand I did not find it so intuitive to use @variadic and @nonVariadic to 
disambiguate.  I would say just pick the trailing comma. 

Thanks

> On Feb 26, 2017, at 12:25 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> I suggest to take a look at the topics "Variadics as an Attribute" and "array 
> splatting for variadic parameters" and 
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
> 
> This is basically the other way round (arrays would accept variadic 
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with 
> types besides array (set, iterator….)
> ___
> 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] Infer types of default function parameters

[Charles Srstka via swift-evolution]

> On Mar 11, 2017, at 3:17 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> As I understood it, omitting the type would work identically to `let` 
> declarations. A string literal without a type defaults to `String`. Treating 
> it as a generic function is a bad idea IMO.
> 
> I don't think this sugar is worth any amount of added complexity. Most 
> function arguments will have not have default values and this have to 
> continue to declare the type, so this would only be more concise in very few 
> cases. I'd prefer the consistency of always having to explicitly declare the 
> argument type at a function boundary.
> 
> To call a function, you need to know what type to pass in. This becomes more 
> difficult when not make explicit, particularly when a more complicated 
> expression is used as a default. -1

When you declare a property with an inferred type, it shows with the explicit 
type in the generated interface. So:

public struct S {
public let foo = 3
}

becomes:

public struct S {
public let foo: Int
}

I would presume that the same rule would apply to default parameters in 
function declarations (although to be fair, I’m also uncertain that we actually 
need this).

Charles

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

Re: [swift-evolution] Infer types of default function parameters

[Jaden Geller via swift-evolution]

Ahh, misunderstanding then. I had thought they were suggesting this was the 
default value of the typealias.

Thanks for clearing that up,
Jaden Geller

> On Mar 11, 2017, at 5:08 PM, Robert Widmann  wrote:
> 
> You may be missing/misspelling the typealias declaration.  This has been in 
> Policy.swift for a while now, and I can reproduce this as far back as 2.2 in 
> the Bluemix sandbox.
> 
> ~Robert Widmann
> 
>> On Mar 11, 2017, at 7:41 PM, Jaden Geller via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Mar 11, 2017, at 3:22 PM, Ben Cohen >> > wrote:
>>> 
 
 On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 
 On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 
>> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> -1
>> 
>> It would be inconsistent to allow it for deterministic literals (String) 
>> and not for non deterministic literal (int which can be either a Int, 
>> Uint, Float, …)
> 
> If I’m not mistaken, even with `bar = “baz”`, `String` is merely the 
> default inferred type. It could be anything that conforms to 
> `ExpressibleByStringLiteral`, right? In that regard, this is kinda just a 
> way to make a function implicitly generic:
> func foo(bar = "baz") {…}
> becomes:
> func foo(bar: T = "baz") {…}
> 
 
 As I understood it, omitting the type would work identically to `let` 
 declarations. A string literal without a type defaults to `String`. 
 Treating it as a generic function is a bad idea IMO.
 
>>> 
>>> More specifically, a string literal without a type defaults to the 
>>> StringLiteralType typealias:
>>> 
>>> typealias StringLiteralType = StaticString
>>> let s = "abc"
>>> print(type(of: s))
>>> // prints StaticString
>> 
>> What version of the Swift compiler are you using? I don’t observe this 
>> behavior. That code prints `String` for me.
>> 
>>> 
 I don't think this sugar is worth any amount of added complexity. Most 
 function arguments will have not have default values and this have to 
 continue to declare the type, so this would only be more concise in very 
 few cases. I'd prefer the consistency of always having to explicitly 
 declare the argument type at a function boundary.
 
 To call a function, you need to know what type to pass in. This becomes 
 more difficult when not make explicit, particularly when a more 
 complicated expression is used as a default. -1
 
> Is there anything we can do with a variable, if all we know of it is that 
> it conforms to `ExpressibleByStringLiteral`? I can’t think of anything… 
> If we had a way to get back the literal string which the variable was 
> initialized with, we could initialize other values with that, but the 
> protocol doesn’t require us to store it. Come to think of it, is there 
> even a way to store a literal value in its “untyped” form? You can 
> declare a variable to of type `IntegerLiteralType`, but the type system 
> then treats it as an `Int`.
> 
> So while it looks nice (to me, anyway) I’m not sure you could actually do 
> anything with it. Or am I looking at this wrong?
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>> ___
>> 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] Infer types of default function parameters

[Robert Widmann via swift-evolution]

You may be missing/misspelling the typealias declaration.  This has been in 
Policy.swift for a while now, and I can reproduce this as far back as 2.2 in 
the Bluemix sandbox.

~Robert Widmann

> On Mar 11, 2017, at 7:41 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> 
>> On Mar 11, 2017, at 3:22 PM, Ben Cohen > > wrote:
>> 
>>> 
>>> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 
> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> -1
> 
> It would be inconsistent to allow it for deterministic literals (String) 
> and not for non deterministic literal (int which can be either a Int, 
> Uint, Float, …)
 
 If I’m not mistaken, even with `bar = “baz”`, `String` is merely the 
 default inferred type. It could be anything that conforms to 
 `ExpressibleByStringLiteral`, right? In that regard, this is kinda just a 
 way to make a function implicitly generic:
 func foo(bar = "baz") {…}
 becomes:
 func foo(bar: T = "baz") {…}
 
>>> 
>>> As I understood it, omitting the type would work identically to `let` 
>>> declarations. A string literal without a type defaults to `String`. 
>>> Treating it as a generic function is a bad idea IMO.
>>> 
>> 
>> More specifically, a string literal without a type defaults to the 
>> StringLiteralType typealias:
>> 
>> typealias StringLiteralType = StaticString
>> let s = "abc"
>> print(type(of: s))
>> // prints StaticString
> 
> What version of the Swift compiler are you using? I don’t observe this 
> behavior. That code prints `String` for me.
> 
>> 
>>> I don't think this sugar is worth any amount of added complexity. Most 
>>> function arguments will have not have default values and this have to 
>>> continue to declare the type, so this would only be more concise in very 
>>> few cases. I'd prefer the consistency of always having to explicitly 
>>> declare the argument type at a function boundary.
>>> 
>>> To call a function, you need to know what type to pass in. This becomes 
>>> more difficult when not make explicit, particularly when a more complicated 
>>> expression is used as a default. -1
>>> 
 Is there anything we can do with a variable, if all we know of it is that 
 it conforms to `ExpressibleByStringLiteral`? I can’t think of anything… If 
 we had a way to get back the literal string which the variable was 
 initialized with, we could initialize other values with that, but the 
 protocol doesn’t require us to store it. Come to think of it, is there 
 even a way to store a literal value in its “untyped” form? You can declare 
 a variable to of type `IntegerLiteralType`, but the type system then 
 treats it as an `Int`.
 
 So while it looks nice (to me, anyway) I’m not sure you could actually do 
 anything with it. Or am I looking at this wrong?
 
 - Dave Sweeris
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

[Xiaodi Wu via swift-evolution]

On Thu, Mar 9, 2017 at 12:34 AM, Ankit Aggarwal via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>> +1, although I don’t know why we're supporting this:
>>
>> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", from: "1.5.8"),
>>
>> when, at least as far as I can tell, this:
>>
>> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8")),
>>
>> does the same thing, and the spelling is, at least to me, clearer as
>> well. Dunno, maybe the “from” version is a term of art that I’m just not
>> familiar with.
>>
>>
> Hi David,
>
> Thank you for the review.
>
> It is true that `from` and `.uptoNextMajor` are exactly same. We think
> that the most widely used requirement will be `.uptoNextMajor`, so we
> wanted to provide a shorthand for it.
>

Kind of a late reply, but overall I think the proposal looks good with the
exception of some of these `Requirement` vs. shorthand dichotomies. It
looks like the following will be synonyms:

```
.package(url: "/SwiftyJSON", branch: "develop")
.package(url: "/SwiftyJSON", .branch("develop"))
```

...as well as...

```
.package(url: "/SwiftyJSON", revision:
"e74b07278b926c9ec6f9643455ea00d1ce04a021")
.package(url: "/SwiftyJSON",
.revision("e74b07278b926c9ec6f9643455ea00d1ce04a021"))
```

It seems odd that there are two subtly different but equivalent ways to
spell the same thing like that. But I get that there are possibilities for
chaining made available with the latter notation and that the former was
promised in a fairly new proposal that's been approved. Where it gets more
unsatisfactory, IMO, is that

```
.package(url: "/SwiftyJSON", .only("1.5.8"))
.package(url: "/SwiftyJSON", .exact("1.5.8"))
```

also seem to mean the same thing. Here, this is actively confusing, because
every user will inevitably scratch their head trying to parse out the
difference. I also share Dave's concern about

```
.package(url: "/SwiftyJSON", from: "1.5.8")
.package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8"))
```

There is no intuition that would tell a user that the two are the same;
after all, `uptoNextMinor` also starts "from" its argument. I understand
that the latter is wordier, but it is not such a grave burden that the
argument label couldn't be rewritten also as `uptoNextMajor`.

While we're on the topic, the standard library spelling is `upTo` rather
than `upto`, and while it's nitpicky I think it's important to go with the
former given that "upto" is not a single word in standard English. If we
wanted this to read more grammatically, consider also `.upToNextMajor(from:
"1.5.8")`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[Jaden Geller via swift-evolution]

> On Mar 11, 2017, at 3:22 PM, Ben Cohen  wrote:
> 
>> 
>> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 -1
 
 It would be inconsistent to allow it for deterministic literals (String) 
 and not for non deterministic literal (int which can be either a Int, 
 Uint, Float, …)
>>> 
>>> If I’m not mistaken, even with `bar = “baz”`, `String` is merely the 
>>> default inferred type. It could be anything that conforms to 
>>> `ExpressibleByStringLiteral`, right? In that regard, this is kinda just a 
>>> way to make a function implicitly generic:
>>> func foo(bar = "baz") {…}
>>> becomes:
>>> func foo(bar: T = "baz") {…}
>>> 
>> 
>> As I understood it, omitting the type would work identically to `let` 
>> declarations. A string literal without a type defaults to `String`. Treating 
>> it as a generic function is a bad idea IMO.
>> 
> 
> More specifically, a string literal without a type defaults to the 
> StringLiteralType typealias:
> 
> typealias StringLiteralType = StaticString
> let s = "abc"
> print(type(of: s))
> // prints StaticString

What version of the Swift compiler are you using? I don’t observe this 
behavior. That code prints `String` for me.

> 
>> I don't think this sugar is worth any amount of added complexity. Most 
>> function arguments will have not have default values and this have to 
>> continue to declare the type, so this would only be more concise in very few 
>> cases. I'd prefer the consistency of always having to explicitly declare the 
>> argument type at a function boundary.
>> 
>> To call a function, you need to know what type to pass in. This becomes more 
>> difficult when not make explicit, particularly when a more complicated 
>> expression is used as a default. -1
>> 
>>> Is there anything we can do with a variable, if all we know of it is that 
>>> it conforms to `ExpressibleByStringLiteral`? I can’t think of anything… If 
>>> we had a way to get back the literal string which the variable was 
>>> initialized with, we could initialize other values with that, but the 
>>> protocol doesn’t require us to store it. Come to think of it, is there even 
>>> a way to store a literal value in its “untyped” form? You can declare a 
>>> variable to of type `IntegerLiteralType`, but the type system then treats 
>>> it as an `Int`.
>>> 
>>> So while it looks nice (to me, anyway) I’m not sure you could actually do 
>>> anything with it. Or am I looking at this wrong?
>>> 
>>> - Dave Sweeris
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[Ben Cohen via swift-evolution]

> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> 
> 
> On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> -1
>>> 
>>> It would be inconsistent to allow it for deterministic literals (String) 
>>> and not for non deterministic literal (int which can be either a Int, Uint, 
>>> Float, …)
>> 
>> If I’m not mistaken, even with `bar = “baz”`, `String` is merely the default 
>> inferred type. It could be anything that conforms to 
>> `ExpressibleByStringLiteral`, right? In that regard, this is kinda just a 
>> way to make a function implicitly generic:
>> func foo(bar = "baz") {…}
>> becomes:
>> func foo(bar: T = "baz") {…}
>> 
> 
> As I understood it, omitting the type would work identically to `let` 
> declarations. A string literal without a type defaults to `String`. Treating 
> it as a generic function is a bad idea IMO.
> 

More specifically, a string literal without a type defaults to the 
StringLiteralType typealias:

typealias StringLiteralType = StaticString
let s = "abc"
print(type(of: s))
// prints StaticString

> I don't think this sugar is worth any amount of added complexity. Most 
> function arguments will have not have default values and this have to 
> continue to declare the type, so this would only be more concise in very few 
> cases. I'd prefer the consistency of always having to explicitly declare the 
> argument type at a function boundary.
> 
> To call a function, you need to know what type to pass in. This becomes more 
> difficult when not make explicit, particularly when a more complicated 
> expression is used as a default. -1
> 
>> Is there anything we can do with a variable, if all we know of it is that it 
>> conforms to `ExpressibleByStringLiteral`? I can’t think of anything… If we 
>> had a way to get back the literal string which the variable was initialized 
>> with, we could initialize other values with that, but the protocol doesn’t 
>> require us to store it. Come to think of it, is there even a way to store a 
>> literal value in its “untyped” form? You can declare a variable to of type 
>> `IntegerLiteralType`, but the type system then treats it as an `Int`.
>> 
>> So while it looks nice (to me, anyway) I’m not sure you could actually do 
>> anything with it. Or am I looking at this wrong?
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Infer types of default function parameters

[Jaden Geller via swift-evolution]

On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:

> 
>> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> -1
>> 
>> It would be inconsistent to allow it for deterministic literals (String) and 
>> not for non deterministic literal (int which can be either a Int, Uint, 
>> Float, …)
> 
> If I’m not mistaken, even with `bar = “baz”`, `String` is merely the default 
> inferred type. It could be anything that conforms to 
> `ExpressibleByStringLiteral`, right? In that regard, this is kinda just a way 
> to make a function implicitly generic:
> func foo(bar = "baz") {…}
> becomes:
> func foo(bar: T = "baz") {…}
> 

As I understood it, omitting the type would work identically to `let` 
declarations. A string literal without a type defaults to `String`. Treating it 
as a generic function is a bad idea IMO.

I don't think this sugar is worth any amount of added complexity. Most function 
arguments will have not have default values and this have to continue to 
declare the type, so this would only be more concise in very few cases. I'd 
prefer the consistency of always having to explicitly declare the argument type 
at a function boundary.

To call a function, you need to know what type to pass in. This becomes more 
difficult when not make explicit, particularly when a more complicated 
expression is used as a default. -1

> Is there anything we can do with a variable, if all we know of it is that it 
> conforms to `ExpressibleByStringLiteral`? I can’t think of anything… If we 
> had a way to get back the literal string which the variable was initialized 
> with, we could initialize other values with that, but the protocol doesn’t 
> require us to store it. Come to think of it, is there even a way to store a 
> literal value in its “untyped” form? You can declare a variable to of type 
> `IntegerLiteralType`, but the type system then treats it as an `Int`.
> 
> So while it looks nice (to me, anyway) I’m not sure you could actually do 
> anything with it. Or am I looking at this wrong?
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[David Sweeris via swift-evolution]

> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution 
>  wrote:
> 
> -1
> 
> It would be inconsistent to allow it for deterministic literals (String) and 
> not for non deterministic literal (int which can be either a Int, Uint, 
> Float, …)

If I’m not mistaken, even with `bar = “baz”`, `String` is merely the default 
inferred type. It could be anything that conforms to 
`ExpressibleByStringLiteral`, right? In that regard, this is kinda just a way 
to make a function implicitly generic:
func foo(bar = "baz") {…}
becomes:
func foo(bar: T = "baz") {…}

Is there anything we can do with a variable, if all we know of it is that it 
conforms to `ExpressibleByStringLiteral`? I can’t think of anything… If we had 
a way to get back the literal string which the variable was initialized with, 
we could initialize other values with that, but the protocol doesn’t require us 
to store it. Come to think of it, is there even a way to store a literal value 
in its “untyped” form? You can declare a variable to of type 
`IntegerLiteralType`, but the type system then treats it as an `Int`.

So while it looks nice (to me, anyway) I’m not sure you could actually do 
anything with it. Or am I looking at this wrong?

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

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

[Jacob Bandes-Storch via swift-evolution]

On Sat, Mar 11, 2017 at 5:34 AM, Brent Royal-Gordon 
wrote:

> > On Mar 10, 2017, at 11:17 PM, Jacob Bandes-Storch 
> wrote:
> >
> > I'm confused by this example — was 
> > ExpressibleByFailableStringInterpolation's
> init() supposed to be failable here?
>
> Ugh, yes, I'm sorry. That should have been:
>
> protocol ExpressibleByFailableStringInterpolation:
> ExpressibleByStringLiteral {
> associatedtype StringInterpolationType
>
> init?(stringInterpolation: StringInterpolationSegment...)
> }
>
> ...
>
> extension Optional: ExpressibleByStringInterpolation where
> Wrapped: ExpressibleByFailableStringInterpolation {
> typealias StringLiteralType = Wrapped.StringLiteralType
> typealias StringInterpolationType =
> Wrapped.StringInterpolationType
>
> init(stringInterpolation segments:
> StringInterpolationSegment...) {
> self = Wrapped(stringInterpolation: segments)
> }
> }
>
> > Just to throw out another idea, what about keeping the entirety of the
> string in one contiguous block and providing String.Indexes to the
> initializer?
> >
> > protocol ExpressibleByStringInterpolation {
> > associatedtype Interpolation
> > init(_ string: String, with interpolations: (String.Index,
> Interpolation)...)
> > }
>
> I've thought about that too. It's a little bit limiting—you have no choice
> except to use `String` as your input type. Also, the obvious way to use
> these parameters:
>
> init(stringLiteral string: String, with interpolations:
> (String.Index, Interpolation)...) {
> var copy = string
> for (i, expr) in interpolations {
> let exprString = doSomething(with: expr)
> copy.insert(exprString, at: i)
> }
> self.string = copy
> }
>
> Will probably be slow, since you're inserting into the middle instead of
> appending to the end. Obviously a clever programmer can avoid doing that,
> but why create the attractive nuisance in the first place?
>

It's also easy to get wrong ;-)  Docs for insert(_:at:) say "Calling this
method invalidates any existing indices for use with this string." And even
if they weren't invalidated, but simple numerical indices as into an Array,
you'd need to use them offsetBy however much content you'd inserted so far.


>
> > On the other hand, unless I've missed something, it seems like most of
> the suggestions so far are assuming that for any
> ExpressibleByStringInterpolation type, the interpolated values' types
> will be homogeneous. In the hypothetical printf-replacement case, you'd
> really want the value types to depend on the format specifiers, so that a
> Float couldn't be passed to %d without explicitly converting to an integer
> type.
> >
> > Although I suppose that could simply be achieved with a typealias
> Interpolation = enum { case f(Float), d(Int), ... }
>
>
> Yup. Given Swift's current feature set, the only way to design this is to
> have a single type which all interpolations funnel through. That type could
> be `Any`, of course, but that doesn't really help anybody.
>
> If we had variadic generics, you could of course have a variadic
> initializer with heterogeneous types. And I've often given thought to a
> "multiple associated types" feature where a protocol could be conformed to
> multiple times by specifying more than one concrete type for specific
> associated types. But these are both exotic features. In their absence, an
> enum (or something like that) is probably the best choice.
>
> * * *
>
> I'm going to try to explore some of these other designs, but they all seem
> to assume the new formatting system I sketched out in "future directions",
> so I implemented that first:
>
> https://github.com/brentdax/swift/compare/new-interpolation.
> ..brentdax:new-interpolation-formatting
>
> The switch to `\(describing: foo)` has more impact than I expected; just
> the code that's built by `utils/build-script`—not including tests—has over
> a hundred lines with changes like this:
>
> -expectationFailure("\(lhs) < \(rhs)", trace: ${trace})
> +expectationFailure("\(describing: lhs) < \(describing: rhs)", trace:
> ${trace})
>
> On the other hand, I like what it does to other formatting (I've only
> applied this kind of change in a few places):
>
> -return "CollectionOfOne(\(String(reflecting: _element)))"
> +return "CollectionOfOne(\(reflecting: _element))"
>
> And it *does* make you think about whether you want to use `describing:`
> or `reflecting:`:
>
> -expectEqual(expected, actual, "where the argument is: \(a)")
> +expectEqual(expected, actual, "where the argument is: \(describing:
> a)")
>
> And, thanks to LosslessStringConvertible, it also does a pretty good job
> of calling out the difference between interpolations that will probably
> look good to 

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

[David Sweeris via swift-evolution]

> On Mar 11, 2017, at 9:49 AM, and...@arnopoulos.io wrote:
> 
> How would that work for a subclass, if all properties of a class need to be 
> initialized before the parent's initializer is called?
> 
> -Andrew
> 
> On Mar 11, 2017, at 8:46 AM, Derrick Ho via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> Seems like it should work. Maybe it is a bug that should be reported to SR.
>> 
>> Does this error occur for non-failable initializers?
>> On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Is this a feature or a bug?
>> class Foo {
>> let bar: Int
>> init?(someConditionBasedOnInputData: Bool) {
>> var localBar: Int = 0
>> defer {
>> bar = localBar //Cannot assign to property: 'bar' is a 'let' 
>> constant
>> }
>> if someConditionBasedOnInputData {
>> return nil
>> }
>> }
>> }
>> It’d be handy to be able to do the assignment upfront in a defer block in 
>> cases where there’s both a bunch of validation to do on the input data, and 
>> no harm from assigning the interim values to the final values when you’re 
>> about to return nil anyway.

If I was trying to subclass something and add extra instance variables, yeah, I 
don’t think it would work. I’m not trying to subclass anything in this case, 
though.

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

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

[David Sweeris via swift-evolution]

> On Mar 11, 2017, at 7:46 AM, Derrick Ho  wrote:
> 
> Seems like it should work. Maybe it is a bug that should be reported to SR.
> 
> Does this error occur for non-failable initializers?

Yep

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

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

[Andrew via swift-evolution]

How would that work for a subclass, if all properties of a class need to be 
initialized before the parent's initializer is called?

-Andrew

> On Mar 11, 2017, at 8:46 AM, Derrick Ho via swift-evolution 
>  wrote:
> 
> Seems like it should work. Maybe it is a bug that should be reported to SR.
> 
> Does this error occur for non-failable initializers?
>> On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution 
>>  wrote:
>> Is this a feature or a bug?
>> class Foo {
>> let bar: Int
>> init?(someConditionBasedOnInputData: Bool) {
>> var localBar: Int = 0
>> defer {
>> bar = localBar //Cannot assign to property: 'bar' is a 'let' 
>> constant
>> }
>> if someConditionBasedOnInputData {
>> return nil
>> }
>> }
>> }
>> It’d be handy to be able to do the assignment upfront in a defer block in 
>> cases where there’s both a bunch of validation to do on the input data, and 
>> no harm from assigning the interim values to the final values when you’re 
>> about to return nil anyway.
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Tino Heth via swift-evolution]

> I'd find it fantastic if they added
> 
> var list: String... = 1, 2,3,4,5

If this list taught me anything, that it is that there is an incredible 
diversity what people like or dislike ;-)

But would you really prefer that (wait a moment: String??? ;-) over
var list: [Int] = 1, 2, 3
or boring old
var list = [1, 2, 3]
?

> However if they remove Variadic arguments then apple would need to remove it 
> from their apis. To name a few...
> 
> print
> NSPredicate(format:)
> UIAlertView
I have to point out that the proposal never aimed to remove variadic call — it 
has even been suggested to allow them for any array (or other types that can be 
constructed from an array literal).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

[Derrick Ho via swift-evolution]

Seems like it should work. Maybe it is a bug that should be reported to SR.

Does this error occur for non-failable initializers?
On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> Is this a feature or a bug?
>
> class Foo {
> let bar: Int
> init?(someConditionBasedOnInputData: Bool) {
> var localBar: Int = 0
> defer {
> bar = localBar //Cannot assign to property: 'bar' is a 'let'
> constant
> }
> if someConditionBasedOnInputData {
> return nil
> }
> }
> }
>
> It’d be handy to be able to do the assignment upfront in a defer block in
> cases where there’s both a bunch of validation to do on the input data, and
> no harm from assigning the interim values to the final values when you’re
> about to return nil anyway.
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[Ben Rimmington via swift-evolution]

Previously:





> On 10 Mar 2017, at 21:40, Kilian Koeltzsch wrote:
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)
> 
> Cheers,
> Kilian
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Derrick Ho via swift-evolution]

I'd find it fantastic if they added

var list: String... = 1, 2,3,4,5

However if they remove Variadic arguments then apple would need to remove
it from their apis. To name a few...

print
NSPredicate(format:)
UIAlertView

Removing variadic arguments would be a breaking change though. They would
either need to remove it quickly or deprecate all the methods that use
variadic arguments. Might take awhile before it is removed completely.


On Sat, Mar 11, 2017 at 4:47 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> foo(["a", "b", "c"] as String...)
>
>
> I like this
>
>
> +1
>
>
> I really don't get this:
> We have methods like NSLayoutConstraint.activate(_ constraints:
> [NSLayoutConstraint]), which works with an array, declares its parameter to
> be array and is called with an array. Quite simple.
>
> On the other hand, we have functions which work with an array, but are
> declared with *Type…*, and are called with a comma-separated list of
> elements — and we should add an option to call this function (which works
> on array!) with an array that is decorated with a strange cast?
> That looks extremely awkward to me.
>
> Can I declare a variable like
> var list: String… = "a"
> ?
> Imho it's better to get rid of these odd types completely.
> ___
> 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] Infer types of default function parameters

[Derrick Ho via swift-evolution]

+1

I like that python style shorthand.
On Sat, Mar 11, 2017 at 6:36 AM Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm always positive with shorthand declarations, though this is a good
> example of ambiguity pron case.
>
> Signatures are signatures. Let's not mess with them.
>
> On Sat, 11 Mar 2017 at 11:19 Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> I sent the message below to swift-users@ ~a day ago, but this might be a
> better place to ask and gather some discussion. It is a rather minor
> suggestion and I'm just looking for some opinions.
>
> Declaring a function that has default parameters currently looks like this:
>
> func foo(bar: String = "baz") {
> print(bar)
> }
>
> Now I'm wondering if there would be any problems if it were possible to
> omit the type annotation for default params and let Swift's type inference
> handle that.
>
> func foo(bar = "baz") {
> print(bar)
> }
>
> It feels to be equivalent to omitting type annotations with variable
> declarations. Obviously more complex types would still require annotations
> being specified. Off the top of my head I can't think of any negative
> ramifications this might bring, be it in simple function/method
> declarations or protocol extensions and elsewhere.
> Any further input or examples for situations where this might cause issues
> would be much appreciated :)
>
>
> I like the idea but I'm afraid I don't think I can support it.
>
> I think it is more important for function/method declarations to have as
> explicit a signature as possible; I mean, I'm not even that comfortable
> with the ability to omit -> Void on non-returning functions (I always
> include it just to be consistent).
>
> As others point out, while this makes sense for types where there's only
> one obvious choice to infer, it's not quite so clear on things like ints
> where a function really needs to be absolutely clear on what type/width of
> int it expects, since it's not something you want to have to change in
> future.
>
> One alternative I thought of was an operator for this purpose, e.g- :=
> (chosen since the colon kind of suits the omitted type declaration); this
> would allow a developer to be explicit about wanting Swift to infer the
> type, but it would be inconsistent with regular variables where it's always
> inferred, so I'm not sure if it'd be a good option anyway.
>
> Sorry, I do agree that it feels inconsistent that a function default
> doesn't behave more like a variable's initialisation, but at the same time
> they *are* two slightly different concepts so that's not necessarily a
> bad thing.
> ___
> 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] [Draft] Fix ExpressibleByStringInterpolation

[Brent Royal-Gordon via swift-evolution]

> On Mar 10, 2017, at 11:17 PM, Jacob Bandes-Storch  wrote:
> 
> I'm confused by this example — was ExpressibleByFailableStringInterpolation's 
> init() supposed to be failable here?

Ugh, yes, I'm sorry. That should have been:

protocol ExpressibleByFailableStringInterpolation: 
ExpressibleByStringLiteral {
associatedtype StringInterpolationType

init?(stringInterpolation: StringInterpolationSegment...)
}

...

extension Optional: ExpressibleByStringInterpolation where Wrapped: 
ExpressibleByFailableStringInterpolation {
typealias StringLiteralType = Wrapped.StringLiteralType
typealias StringInterpolationType = 
Wrapped.StringInterpolationType

init(stringInterpolation segments: 
StringInterpolationSegment...) {
self = Wrapped(stringInterpolation: segments)
}
}

> Just to throw out another idea, what about keeping the entirety of the string 
> in one contiguous block and providing String.Indexes to the initializer?
> 
> protocol ExpressibleByStringInterpolation {
> associatedtype Interpolation
> init(_ string: String, with interpolations: (String.Index, 
> Interpolation)...)
> }

I've thought about that too. It's a little bit limiting—you have no choice 
except to use `String` as your input type. Also, the obvious way to use these 
parameters:

init(stringLiteral string: String, with interpolations: (String.Index, 
Interpolation)...) {
var copy = string
for (i, expr) in interpolations {
let exprString = doSomething(with: expr)
copy.insert(exprString, at: i)
}
self.string = copy
}

Will probably be slow, since you're inserting into the middle instead of 
appending to the end. Obviously a clever programmer can avoid doing that, but 
why create the attractive nuisance in the first place?

> On the other hand, unless I've missed something, it seems like most of the 
> suggestions so far are assuming that for any ExpressibleByStringInterpolation 
> type, the interpolated values' types will be homogeneous. In the hypothetical 
> printf-replacement case, you'd really want the value types to depend on the 
> format specifiers, so that a Float couldn't be passed to %d without 
> explicitly converting to an integer type.
> 
> Although I suppose that could simply be achieved with a typealias 
> Interpolation = enum { case f(Float), d(Int), ... }


Yup. Given Swift's current feature set, the only way to design this is to have 
a single type which all interpolations funnel through. That type could be 
`Any`, of course, but that doesn't really help anybody.

If we had variadic generics, you could of course have a variadic initializer 
with heterogeneous types. And I've often given thought to a "multiple 
associated types" feature where a protocol could be conformed to multiple times 
by specifying more than one concrete type for specific associated types. But 
these are both exotic features. In their absence, an enum (or something like 
that) is probably the best choice.

* * *

I'm going to try to explore some of these other designs, but they all seem to 
assume the new formatting system I sketched out in "future directions", so I 
implemented that first:


https://github.com/brentdax/swift/compare/new-interpolation...brentdax:new-interpolation-formatting

The switch to `\(describing: foo)` has more impact than I expected; just the 
code that's built by `utils/build-script`—not including tests—has over a 
hundred lines with changes like this:

-expectationFailure("\(lhs) < \(rhs)", trace: ${trace})
+expectationFailure("\(describing: lhs) < \(describing: rhs)", trace: 
${trace})

On the other hand, I like what it does to other formatting (I've only applied 
this kind of change in a few places):

-return "CollectionOfOne(\(String(reflecting: _element)))"
+return "CollectionOfOne(\(reflecting: _element))"

And it *does* make you think about whether you want to use `describing:` or 
`reflecting:`:

-expectEqual(expected, actual, "where the argument is: \(a)")
+expectEqual(expected, actual, "where the argument is: \(describing: a)")

And, thanks to LosslessStringConvertible, it also does a pretty good job of 
calling out the difference between interpolations that will probably look good 
to a user and ones that will look a little funny:

-  return "watchOS(\(major).\(minor).[\(bugFixRange)], reason: \(reason))"
+  return "watchOS(\(major).\(minor).[\(describing: bugFixRange)], reason: 
\(reason))"

All in all, it's a bit of a mixed bag:

-  return "<\(type(of: x)): 0x\(String(asNumericValue(x), radix: 16, 
uppercase: false))>"
+  return "<\(describing: type(of: x)): 0x\(asNumericValue(x), radix: 
16, uppercase: false)>"

We could probably

Re: [swift-evolution] Infer types of default function parameters

[Daniel Leping via swift-evolution]

I'm always positive with shorthand declarations, though this is a good
example of ambiguity pron case.

Signatures are signatures. Let's not mess with them.

On Sat, 11 Mar 2017 at 11:19 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> I sent the message below to swift-users@ ~a day ago, but this might be a
> better place to ask and gather some discussion. It is a rather minor
> suggestion and I'm just looking for some opinions.
>
> Declaring a function that has default parameters currently looks like this:
>
> func foo(bar: String = "baz") {
> print(bar)
> }
>
> Now I'm wondering if there would be any problems if it were possible to
> omit the type annotation for default params and let Swift's type inference
> handle that.
>
> func foo(bar = "baz") {
> print(bar)
> }
>
> It feels to be equivalent to omitting type annotations with variable
> declarations. Obviously more complex types would still require annotations
> being specified. Off the top of my head I can't think of any negative
> ramifications this might bring, be it in simple function/method
> declarations or protocol extensions and elsewhere.
> Any further input or examples for situations where this might cause issues
> would be much appreciated :)
>
>
> I like the idea but I'm afraid I don't think I can support it.
>
> I think it is more important for function/method declarations to have as
> explicit a signature as possible; I mean, I'm not even that comfortable
> with the ability to omit -> Void on non-returning functions (I always
> include it just to be consistent).
>
> As others point out, while this makes sense for types where there's only
> one obvious choice to infer, it's not quite so clear on things like ints
> where a function really needs to be absolutely clear on what type/width of
> int it expects, since it's not something you want to have to change in
> future.
>
> One alternative I thought of was an operator for this purpose, e.g- :=
> (chosen since the colon kind of suits the omitted type declaration); this
> would allow a developer to be explicit about wanting Swift to infer the
> type, but it would be inconsistent with regular variables where it's always
> inferred, so I'm not sure if it'd be a good option anyway.
>
> Sorry, I do agree that it feels inconsistent that a function default
> doesn't behave more like a variable's initialisation, but at the same time
> they *are* two slightly different concepts so that's not necessarily a
> bad thing.
> ___
> 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] Variadic Arguments should accept Arrays

[Tino Heth via swift-evolution]

>>> foo(["a", "b", "c"] as String...) 
>> 
>> I like this
> 
> +1

I really don't get this:
We have methods like NSLayoutConstraint.activate(_ constraints: 
[NSLayoutConstraint]), which works with an array, declares its parameter to be 
array and is called with an array. Quite simple.

On the other hand, we have functions which work with an array, but are declared 
with Type…, and are called with a comma-separated list of elements — and we 
should add an option to call this function (which works on array!) with an 
array that is decorated with a strange cast?
That looks extremely awkward to me.

Can I declare a variable like
var list: String… = "a"
?
Imho it's better to get rid of these odd types completely.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[Haravikk via swift-evolution]

> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)

I like the idea but I'm afraid I don't think I can support it.

I think it is more important for function/method declarations to have as 
explicit a signature as possible; I mean, I'm not even that comfortable with 
the ability to omit -> Void on non-returning functions (I always include it 
just to be consistent).

As others point out, while this makes sense for types where there's only one 
obvious choice to infer, it's not quite so clear on things like ints where a 
function really needs to be absolutely clear on what type/width of int it 
expects, since it's not something you want to have to change in future.

One alternative I thought of was an operator for this purpose, e.g- := (chosen 
since the colon kind of suits the omitted type declaration); this would allow a 
developer to be explicit about wanting Swift to infer the type, but it would be 
inconsistent with regular variables where it's always inferred, so I'm not sure 
if it'd be a good option anyway.

Sorry, I do agree that it feels inconsistent that a function default doesn't 
behave more like a variable's initialisation, but at the same time they are two 
slightly different concepts so that's not necessarily a bad thing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[Jean-Daniel via swift-evolution]

-1

It would be inconsistent to allow it for deterministic literals (String) and 
not for non deterministic literal (int which can be either a Int, Uint, Float, 
…)

> Le 10 mars 2017 à 22:40, Kilian Koeltzsch via swift-evolution 
>  a écrit :
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)
> 
> Cheers,
> Kilian
> ___
> 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] Infer types of default function parameters

[Rien via swift-evolution]

0

Its not something I would use, but I don’t see why not.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 10 Mar 2017, at 22:40, Kilian Koeltzsch via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)
> 
> Cheers,
> Kilian
> ___
> 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