Could enums have their rawValue type inferred?


(Eric Miller) #1

automatically cast rawValue when assigning an enum value to

a variable or argument of the type of the enum's raw value

That's exactly what I'm thinking, Leonardo. I was a little bit trying to
avoid specifics because I don't understand the differences between
autocasting and inference.

There's a small miscommunication though--I've built api to accept the enum
type. Signature:

static func fadeIn(view: UIView?, withSpeed: Animate.transitionSpeed =
Animate.transitionSpeed.fast)

The goal was to provide my users with a good default and an easy set of
configurable options at the call site like `.fast`, `.normal`, `.slow`.

(unrelated: +1 on inferring type of function params with default values, I
hit this all the time)

Calling:

Animate.fadeIn(myView, withSpeed: .slow)

Works great.

This library of methods is a facade for CABasicAnimation or UIView
animations which take an NSTimeInterval, and that's where the "autocasting"
would come into play.

···

------------------------------

Message: 31
Date: Fri, 13 May 2016 16:58:06 -0300
From: Leonardo Pessoa <me@lmpessoa.com>
To: Swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Could enums have their rawValue type
        inferred?
Message-ID:
        <CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Eric, I think I understood your proposal. If I may explain in other words
it would be "to automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value", am I right? I
think this would imply a little more inference and type checking rules from
the compiler and maybe even take a little longer to fully compile code. I'm
not sure it's feasible but from your examples, I can see how it enhances
readability of the code, so I'm +1 for it. My only concern is that you
would still need to fully declare the enum's name where the value of the
enum is used. Taking from your own example

    Animate.fadeIn(view, withSpeed: .fast)

couldn't be called that way if withSpeed expects and NSTimeInterval because
the compiler won't know whether you're refering to transitionSpeed or to
ambientAnimationSpeed. You would still have to call it like

    Animate.fadeIn(view, withSpeed: transitionSpeed.fast)

even if you had only one possible enum value over all declared enums
because that would still force the compiler to search for each value over
all known enums to define where the value you're using comes from and make
sure there are no two enums with the same value.

Aside from that, I good with the idea.

On 13 May 2016 at 15:09, Eric Miller via swift-evolution < swift-evolution@swift.org> wrote:

This might open a larger can of worms than I imagine, but what do you
folks think about using the `rawValue` of an enum when that rawValue is a
fit for the expected type?

Use case.

I'm making an animation facade, and it has some speed presets:

class Animate {
  enum transitionSpeed: NSTimeInterval {
    case fast = 0.15
    case slow = 0.5
  }
  enum ambientAnimationSpeed: NSTimeInterval {
    case fast = 1.0
    case slow = 5.0
  }
  ...
}

I did them with static variables at first but that made the call site
verbose. Compare:

Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
Animate.fadeIn(view, withSpeed: .fast)

So, I like the enum approach better, but my library code has to use
`rawValue` to do anything with the actual value, of course:

static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
.fast) {
  ...
  UIView.animateWithDuration(duration.rawValue, animations: { })
}

It's not a serious issue, but the code is more clear and beautiful if it
has just myIntent, rather than myIntent.rawValue.

I've hit this issue when modeling other things, such as:

* server fault codes
* HTTP status codes
* Currency codes
* Days of the week

Would it be appropriate to "autocast" to the rawValue of the enum when the
rawValue's Type matches the type expectation of the API? Or would this
introduce a bunch of type system uncertainty?

Maybe this could be implemented as a protocol? It feels almost like the
convenience of `CustomStringConvertible`'s `description` property.

On Fri, May 13, 2016 at 11:24 PM, <swift-evolution-request@swift.org> wrote:

Send swift-evolution mailing list submissions to
        swift-evolution@swift.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.swift.org/mailman/listinfo/swift-evolution
or, via email, send a message with subject or body 'help' to
        swift-evolution-request@swift.org

You can reach the person managing the list at
        swift-evolution-owner@swift.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of swift-evolution digest..."

Today's Topics:

   1. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Vladimir.S)
   2. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Vladimir.S)
   3. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Ross O'Brien)
   4. Re: Removing "_ in" from empty closures (Cole Campbell)
   5. Re: [Review] SE-0084: Allow trailing commas in parameter
      lists and tuples (Joe Groff)
   6. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Adrian Zubarev)
   7. Re: [Review] SE-0084: Allow trailing commas in parameter
      lists and tuples (Joe Groff)
   8. Re: [Review] SE-0084: Allow trailing commas in parameter
      lists and tuples (Vladimir.S)
   9. Re: [Review] SE-0084: Allow trailing commas in parameter
      lists and tuples (Erica Sadun)
  10. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Adrian Zubarev)
  11. Re: Removing "_ in" from empty closures (Erica Sadun)
  12. Re: [swift-evolution-announce] [Review] SE-0041: Updating
      Protocol Naming Conventions for Conversions (Pyry Jahkola)
  13. Could enums have their rawValue type inferred? (Eric Miller)
  14. Re: [Draft] Introducing StaticSelf, an Invariant Self
      (Nicola Salmoria)
  15. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),
      and iterate to the stdlib (Erica Sadun)
  16. Re: [Review] SE-0075: Adding a Build Configuration Import
      Test (Pyry Jahkola)
  17. [draft-proposal] allow access to the underlying collection of
      a slice (Max Moiseev)
  18. Re: [Review] SE-0084: Allow trailing commas in parameter
      lists and tuples (Joe Groff)
  19. Interspersing guard let with guard boolean (Erica Sadun)
  20. Re: Interspersing guard let with guard boolean (Joe Groff)
  21. Re: Interspersing guard let with guard boolean (Erica Sadun)
  22. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Vladimir.S)
  23. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
      naming conventions (Matt Wright)
  24. Re: [Draft] Introducing StaticSelf, an Invariant Self
      (Matthew Johnson)
  25. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),
      and iterate to the stdlib (Kevin Ballard)
  26. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Adrian Zubarev)
  27. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
      naming conventions (Jacob Bandes-Storch)
  28. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
      naming conventions (Xiaodi Wu)
  29. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
      naming conventions (Matt Wright)
  30. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
      naming conventions (Matt Wright)
  31. Re: Could enums have their rawValue type inferred?
      (Leonardo Pessoa)
  32. Re: Removing "_ in" from empty closures (Jacob Bandes-Storch)
  33. Re: Removing "_ in" from empty closures (Matthew Johnson)
  34. Re: [Draft] Introducing StaticSelf, an Invariant Self (Joe
Groff)
  35. Re: Removing "_ in" from empty closures (Joe Groff)
  36. Re: [Review] SE-0084: Allow trailing commas in parameter
      lists and tuples (John Siracusa)
  37. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Vladimir.S)
  38. Re: [Draft] Introducing StaticSelf, an Invariant Self (Vladimir.S)
  39. Re: Removing "_ in" from empty closures (Matthew Johnson)
  40. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
      naming conventions (Matt Wright)
  41. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Adrian Zubarev)
  42. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Matthew Johnson)
  43. Re: [Draft] Introducing StaticSelf, an Invariant Self
      (Matthew Johnson)
  44. Re: [Pitch] merge types and protocols back together with
      type<Type, Protocol, ...> (Austin Zheng)
  45. Re: [Review] SE-0081: Move where clause to end of declaration
      (Jon Shier)
  46. Re: [Pitch] Consistent bridging for NSErrors at the language
      boundary (Jon Shier)
  47. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),
      and iterate to the stdlib (Patrick Smith)

----------------------------------------------------------------------

Message: 1
Date: Fri, 13 May 2016 20:04:46 +0300
From: "Vladimir.S" <svabox@gmail.com>
To: Adrian Zubarev <adrian.zubarev@devandartist.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <2f3fbb45-173f-15b4-492d-c059899d5482@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:
> Why would you want to add all of these different formats where only one
> could serve them all. This is redundant in my opinion.
>
> `struct<>` and `enum<>` would have same rules, only the first element
would
> be a different value-type. I might consider this as an alternative.
>

Actually, I fully support your idea and strongly +1 for `type<>` keyword. I
don't believe it will confuse anyone as protocol<> does not confuse
currently.

But as I can see, the community(or core team) is strongly against of using
`type` keyword.
So, we have situation : protocol<> and .. all<> ? Will all<> include
protocols also? Probably I'd support to remove protocol<> and introduce
just all<> for all :slight_smile: But if we have protocol<> and can't have type<> - I
asked why we can't for clarity and consistency have class<> struct<>

------------------------------

Message: 2
Date: Fri, 13 May 2016 20:08:57 +0300
From: "Vladimir.S" <svabox@gmail.com>
To: Adrian Zubarev <adrian.zubarev@devandartist.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <b8fdfea7-e174-718e-5b28-6ec373f1d8b4@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Btw, if we'd have separate class<> and struct<> - we'd be able to have
method to separate reference type from value type.

We can write now : print(c is protocol<>)

and we'd can:

print(c is class<>)
print(c is struct<>)

Just thoughts..

On 13.05.2016 20:04, Vladimir.S wrote:
> On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:
>> Why would you want to add all of these different formats where only one
>> could serve them all. This is redundant in my opinion.
>>
>> `struct<>` and `enum<>` would have same rules, only the first element
would
>> be a different value-type. I might consider this as an alternative.
>>
>
> Actually, I fully support your idea and strongly +1 for `type<>`
keyword. I
> don't believe it will confuse anyone as protocol<> does not confuse
currently.
>
> But as I can see, the community(or core team) is strongly against of
using
> `type` keyword.
> So, we have situation : protocol<> and .. all<> ? Will all<> include
> protocols also? Probably I'd support to remove protocol<> and introduce
> just all<> for all :slight_smile: But if we have protocol<> and can't have type<> -
I
> asked why we can't for clarity and consistency have class<> struct<>

------------------------------

Message: 3
Date: Fri, 13 May 2016 18:11:11 +0100
From: "Ross O'Brien" <narrativium+swift@gmail.com>
To: Adrian Zubarev <adrian.zubarev@devandartist.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID:
        <
CAPUwzK55PQYDT4j1UBS69KSo410xKWR3js9dY1W8cBsjJshU6g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

In reply to:

Why would you want to add all of these different formats where only one
could serve them all. This is redundant in my opinion.

`struct<>` and `enum<>` would have same rules, only the first element would
be a different value-type. I might consider this as an alternative.

Correct me if I’m wrong with the redundancy.

'enum<>' might be valid, unless their functions (e.g. for 'init(rawValue:
Int)' or 'allCases') are declared in explicit protocols which would
implicitly cover enums and which other types could declare conformance to.

'struct<>' does seem redundant unless it becomes subtypeable. If you want a
struct which conforms to several protocols, protocol<> already covers this.
I know there's a discussion at the moment regarding the equivalent of an
'AnyObject' for value types, which might apply to this discussion, but I'm
not sure how.

A class in general would also a protocol<AnyObject, ...>. The benefit of
'type<>' is in its ability to extend the behaviours of several subclasses
at once, e.g. type<UIViewController, UIScrollViewDelegate> covers all view
controllers with scroll views, not just UITableViewController,
UICollectionViewController, etc..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4ace2772/attachment-0001.html
>

------------------------------

Message: 4
Date: Fri, 13 May 2016 12:14:23 -0500
From: Cole Campbell <cole.m.campbell@icloud.com>
To: Joe Groff <jgroff@apple.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures
Message-ID: <4FC7FC81-FDF2-471D-8C0E-DA5A037AA6D3@icloud.com>
Content-Type: text/plain; charset=us-ascii

> +1. In general, I think we should allow implicit arguments, without
requiring the closure to use all the implicit $n variables like we do
today. These should all be valid:
>
> let _: () -> () = {}
> let _: (Int) -> () = {}
> let _: (Int, Int) -> Int = { 5 }
> let _: (Int, Int) -> Int = { $0 }
> let _: (Int, Int) -> Int = { $1 }

+1. This would be excellent.

------------------------------

Message: 5
Date: Fri, 13 May 2016 10:29:01 -0700
From: Joe Groff <jgroff@apple.com>
To: Erica Sadun <erica@ericasadun.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
        in parameter lists and tuples
Message-ID: <304E28A1-D8D0-43A2-BF7A-FBAEF8828F6D@apple.com>
Content-Type: text/plain; charset=utf-8

> On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:
>
> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:
>>>> You’re arguing that you want to read Swift code written like this?
>>>
>>> I wouldn't mind it.
>>
>> I personally find that style repulsive :slight_smile: and I haven’t seen swift
code commonly doing it. I’m not sure that we want to encourage it either.
>>
>
> No. Tell us what you *really* think of the style. Don't hold back.[1]
>
>> If we were really concerned about this, a narrower way to solve the
same problem would be to allow a comma before the ), but *only* when there
is a newline between them. I still don’t see why we’d want to encourage
this though.
>
> I wouldn't object to this restriction. I cannot think of a situation
where using ",)" -- that is the comma adjacent to a closing parenthesis --
makes sense for any reason previously enumerated in support of this
proposal.

I don't see why we need to micromanage the situations where trailing
commas are allowed. That's just unnecessarily increasing the fractal
complexity of the language. We've delegated other style choices like
requiring `self.` or brace formatting to linters; why does this one need to
be legislated by the compiler?

-Joe

------------------------------

Message: 6
Date: Fri, 13 May 2016 19:32:34 +0200
From: Adrian Zubarev <adrian.zubarev@devandartist.com>
To: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <etPan.57360fb2.5ed02b43.6ab2@DevAndArtist.fritz.box>
Content-Type: text/plain; charset="utf-8"

'struct<>' does seem redundant unless it becomes subtypeable. If you want
a struct which conforms to several protocols, protocol<> already covers
this.
I think this is not correct. Lets check this example:

func foo(value: SomeProtocol) {

    if let a = value as? struct<StructA, SomeProtocol> { /* do something
with a */ }

    else if let b = value as? struct<StructB, SomeProtocol> { /* do
something with b */ }

}

In this scenario you’ll be able to access properties and functions from
`StructA` or `StructB` which might not be covered by `SomeProtocol`.
Everything is merged nicely into one instance. But you are right it depends
on the use-case.

Btw, if we'd have separate class<> and struct<> - we'd be able to
have method to separate reference type from value type.
We can write now : print(c is protocol<>)
and we'd can:
print(c is class<>)
print(c is struct<>)

True, I didn’t thought about that effect at the first glance, thank you
for the hint. I will add this to the draft proposal tomorrow.

--
Adrian Zubarev
Sent with Airmail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4a9f75e9/attachment-0001.html
>

------------------------------

Message: 7
Date: Fri, 13 May 2016 10:32:34 -0700
From: Joe Groff <jgroff@apple.com>
To: Matthew Johnson <matthew@anandabits.com>, Matthew Johnson via
        swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
        in parameter lists and tuples
Message-ID: <76E430C3-01EF-45B3-B00E-01490E75DCAA@apple.com>
Content-Type: text/plain; charset=utf-8

> On May 13, 2016, at 7:32 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPad
>
>> On May 13, 2016, at 9:19 AM, Vladimir.S <svabox@gmail.com> wrote:
>>
>>> On 13.05.2016 16:32, Matthew Johnson wrote:
>>> I am, +1 on allowing new lines instead of commas. I suggest you
pursue a proposal on that.
>>
>> Unfortunately I have no ability for this right now, so someone who is
interested in this could take the idea and create a 'formal' proposal.
>>
>>>
>>> I am also +1 on the current proposal because it exists and will be
pretty useful in some cases and I can't predict how long it might be until
such a new line proposal would be approved. I also think that the choice
between them should be a style choice, not one made by the language (as
with semicolon) and if anyone chooses commas they should have the utility
of the current proposal available to them.
>>
>> Don't you feel like this proposal(SE-0084) should be extended to list
of generic types at least, or even to allow trailing comma in any
comma-separated list in Swift? I.e. you are saying +1, but probably the
exact proposal should be improved to have your +1.
>
> I have no opinion on that. I don't object to it being done in the name
of consistency but can't think of any actual use cases either.
>>
>> Probably (if this is allowed) the author of this proposal (SE-0084) can
add 'line-break separator feature' to his/her proposal and generalize the
rule of trailing comma/line-breaks for any comma-separated list in Swift?
>
> That feels like a separate proposal to me.

I agree, allowing commas to be elided at line breaks is an interesting
direction that deserves its own discussion. One problem that immediately
comes to my mind is commas in generic parameter lists. If commas aren't
required in generic parameter lists, it becomes even more challenging to
disambiguate with less-than/greater-than expressions at top level,
compromising our ability to shed `.self` for this purpose.

-Joe

>>
>> As I can see, the proposal SE-0084 'per se' has more negative comments
than positive(even if some from @apple.com supports it) and I feel like
extended proposal can have more support.
>>
>>>
>>> Sent from my iPad
>>>
>>>> On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:
>>>>
>>>> IMO If we were *really* concerned about this, we should just allow
line-break as separator in comma-separated lists.
>>>>
>>>>> On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:
>>>>> If we were really concerned about this, a narrower way to solve the
same problem would be to allow a comma before the ), but *only* when there
is a newline between them. I still don’t see why we’d want to encourage
this though.
>>>> _______________________________________________
>>>> 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

------------------------------

Message: 8
Date: Fri, 13 May 2016 20:42:10 +0300
From: "Vladimir.S" <svabox@gmail.com>
To: Joe Groff <jgroff@apple.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
        in parameter lists and tuples
Message-ID: <d487fba4-581b-2c76-145e-b7b79477b395@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Support. *all or nothing* :slight_smile:

On 13.05.2016 20:29, Joe Groff via swift-evolution wrote:
> I don't see why we need to micromanage the situations where trailing
commas are allowed. That's just unnecessarily increasing the fractal
complexity of the language. We've delegated other style choices like
requiring `self.` or brace formatting to linters; why does this one need to
be legislated by the compiler?

------------------------------

Message: 9
Date: Fri, 13 May 2016 11:46:39 -0600
From: Erica Sadun <erica@ericasadun.com>
To: Joe Groff <jgroff@apple.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
        in parameter lists and tuples
Message-ID: <A9ADA97C-DB1F-4556-A290-36BBE2357975@ericasadun.com>
Content-Type: text/plain; charset="utf-8"

> On May 13, 2016, at 11:29 AM, Joe Groff <jgroff@apple.com> wrote:
>
>>
>> On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:
>>
>> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:
>>>>> You’re arguing that you want to read Swift code written like this?
>>>>
>>>> I wouldn't mind it.
>>>
>>> I personally find that style repulsive :slight_smile: and I haven’t seen swift
code commonly doing it. I’m not sure that we want to encourage it either.
>>>
>>
>> No. Tell us what you *really* think of the style. Don't hold back.[1]
>>
>>> If we were really concerned about this, a narrower way to solve the
same problem would be to allow a comma before the ), but *only* when there
is a newline between them. I still don’t see why we’d want to encourage
this though.
>>
>> I wouldn't object to this restriction. I cannot think of a situation
where using ",)" -- that is the comma adjacent to a closing parenthesis --
makes sense for any reason previously enumerated in support of this
proposal.
>
> I don't see why we need to micromanage the situations where trailing
commas are allowed. That's just unnecessarily increasing the fractal
complexity of the language. We've delegated other style choices like
requiring `self.` or brace formatting to linters; why does this one need to
be legislated by the compiler?
>
> -Joe

Mostly because I'm trying to play nice and get Chris to reconsider. I'd
like to get the feature, I'm willing to compromise on the technicalities.
Having it would make my coding life significantly easier and if a little
micromanagement is involved, I'm not terribly fussed. When I need trailing
commas, it's always at the ends of lines anyway.

But since I don't want to undercut you, so I'd much prefer to step back
and defer to your judgement on this.

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/5fa7ba20/attachment-0001.html
>

------------------------------

Message: 10
Date: Fri, 13 May 2016 19:50:38 +0200
From: Adrian Zubarev <adrian.zubarev@devandartist.com>
To: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <etPan.573613ee.5477cc5d.6ab2@DevAndArtist.fritz.box>
Content-Type: text/plain; charset="utf-8"

'struct<>' does seem redundant unless it becomes subtypeable. If you want
a struct which conforms to several protocols, protocol<> already covers
this.
I think this is not correct. Lets check this example:

func foo(value: SomeProtocol) {

    if let a = value as? struct<StructA, SomeProtocol> { /* do something
with a */ }

    else if let b = value as? struct<StructB, SomeProtocol> { /* do
something with b */ }

}

In this scenario you’ll be able to access properties and functions from
`StructA` or `StructB` which might not be covered by `SomeProtocol`.
Everything is merged nicely into one instance. But you are right it depends
on the use-case.

There is no need to include the protocol here. Just do this:

if let a = value as? StructA { use a }

Whoops, I forgot that this will do the trick. I apologize for any
confusion here, you are totally right.

That been said, do we really need `type<>` aka. `all<>` for value types? I
need to rethink this part of the proposal. Is there any use-case where we
would need this (any scenario for the future Swift version also counts)?

If we had `all<>` in Swift already for extendable reference types and one
day structs would become subtypeable, this wouldn’t be a huge problem to
upgrade `all<>` for structs I guess.

--
Adrian Zubarev
Sent with Airmail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b51d2c61/attachment-0001.html
>

------------------------------

Message: 11
Date: Fri, 13 May 2016 11:48:30 -0600
From: Erica Sadun <erica@ericasadun.com>
To: Cole Campbell <cole.m.campbell@icloud.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures
Message-ID: <2F3D83D2-2785-4778-B7C1-91B0EF2381D1@ericasadun.com>
Content-Type: text/plain; charset=us-ascii

On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> +1. In general, I think we should allow implicit arguments, without
requiring the closure to use all the implicit $n variables like we do
today. These should all be valid:
>>
>> let _: () -> () = {}
>> let _: (Int) -> () = {}
>> let _: (Int, Int) -> Int = { 5 }
>> let _: (Int, Int) -> Int = { $0 }
>> let _: (Int, Int) -> Int = { $1 }
>
> +1. This would be excellent.

+1. Good riddance to bad code baggage.

-- E

------------------------------

Message: 12
Date: Fri, 13 May 2016 21:03:19 +0300
From: Pyry Jahkola <pyry.jahkola@iki.fi>
To: Matthew Johnson <matthew@anandabits.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] [swift-evolution-announce] [Review]
        SE-0041: Updating Protocol Naming Conventions for
Conversions
Message-ID: <1AAA5C78-073C-4515-80E6-AC64888FC725@iki.fi>
Content-Type: text/plain; charset="utf-8"

Taking the suggested changes into account, here's my review.

1) +1, I think this is a reasonable way for naming this family of
protocols.

2) The problem isn't huge, but I think it's worth fixing. So far, the
naming of stdlib protocols has been somewhat inconsistent in this regard.

3) I've used other languages & stdlibs with similar naming schemes,
although none of them used the words "initializable" and "representable".
Common alternatives have been word compositions involving expressions such
as "convertible", "from", "to", "bi(jective)", "can build". However, I
think "init" is so central in Swift that the use of "Initializable" is well
justified. "Representable" is slightly less so but self-explanatory IMO,
and more so than "convertible" which could be understood either or both
ways.

4) Quick reading.

— Pyry

> On 13 May 2016, Matthew Johnson wrote:
>
> While the community feedback on our SE-0041 proposal "Updating Protocol
Naming Conventions for Conversions" (
https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
<
https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md>)
has been positive about the need to establish conventions, feedback has
been mixed to negative with regard to the specific conventions suggested in
the proposal.
>
> With that in mind, Erica and I have been working on refactoring those
recommendations. We put together the following update and invite the
community to bikeshed further with us. We hope this offers the Swift core
team the flexibility to accept our proposal "with revision" if an
alternative garners more support. With luck, we'll reach a naming consensus
during the review period.
>
> UPDATED APPROACH
>
> Our updated approach focuses on the two most important conventions: one
for initialization and one for representation.
>
> 1. `Initializable`
>
> `Initializable` designates protocols that convert *from* a type or from
an associated type mentioned in the protocol name, such as the current
`<Type>LiteralConvertible` protocols. This convention would include member
requirements for initializers, factory methods, and any other way an
instance can be imported to establish a new instance of the conforming type.
>
> For example, conforming to `ArrayLiteralInitializable` would allow a set
to be created with `Set(arrayLiteral: <some array>)` and `var set: Set<T> =
[]`.
>
> This phrase replaces the `Creatable` form from our original proposal.
>
> 2. `Representable`
>
> `Representable` designates protocols whose primary purpose is to project
*to* a type or associated type mentioned in the protocol name. Items in
the standard library that would be subsumed into this naming include
`CustomStringConvertible`, `CustomDebugStringConvertible`, and
`RawRepresentable`, which we imagine would become
`CustomStringRepresentable`, `CustomDebugStringRepresentable`, and (as
current) `RawRepresentable`.
>
> This second category groups together the `Convertible` and
`Representable` categories from our original proposal and is predicated on
the feedback from the design team review. The `Representable` designation
does not promise bidirectional conversion although some `Representable`
protocols may include requirements to allow attempted initialization *from*
the type of the representation. Doing so falls outside the naming contract
we are proposing.
>
> FUTURE DIRECTIONS
>
> We did not include a third category for bidirectional conversion in this
update. We recognize that style of contract is rare in Swift. Lossless
conversion does not appear in the standard library outside of
`RawRepresentable`, which we agreed was better covered by `Representable`.
If such a convention is needed or adopted, we reserve the `Isomorphic`
designation for future use.
>
> Sent from my iPad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b88c8136/attachment-0001.html
>

------------------------------

Message: 13
Date: Fri, 13 May 2016 12:09:01 -0600
From: Eric Miller <hi@simple.gy>
To: swift-evolution@swift.org
Subject: [swift-evolution] Could enums have their rawValue type
        inferred?
Message-ID:
        <CAJaDgbjTQMo8keEa=
4+neJp_yPgRpi3rdsSnrAMmwJbonLQEKQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

This might open a larger can of worms than I imagine, but what do you folks
think about using the `rawValue` of an enum when that rawValue is a fit for
the expected type?

Use case.

I'm making an animation facade, and it has some speed presets:

class Animate {
  enum transitionSpeed: NSTimeInterval {
    case fast = 0.15
    case slow = 0.5
  }
  enum ambientAnimationSpeed: NSTimeInterval {
    case fast = 1.0
    case slow = 5.0
  }
  ...
}

I did them with static variables at first but that made the call site
verbose. Compare:

Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
Animate.fadeIn(view, withSpeed: .fast)

So, I like the enum approach better, but my library code has to use
`rawValue` to do anything with the actual value, of course:

static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
.fast) {
  ...
  UIView.animateWithDuration(duration.rawValue, animations: { })
}

It's not a serious issue, but the code is more clear and beautiful if it
has just myIntent, rather than myIntent.rawValue.

I've hit this issue when modeling other things, such as:

* server fault codes
* HTTP status codes
* Currency codes
* Days of the week

Would it be appropriate to "autocast" to the rawValue of the enum when the
rawValue's Type matches the type expectation of the API? Or would this
introduce a bunch of type system uncertainty?

Maybe this could be implemented as a protocol? It feels almost like the
convenience of `CustomStringConvertible`'s `description` property.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/c7c83773/attachment-0001.html
>

------------------------------

Message: 14
Date: Fri, 13 May 2016 20:11:12 +0200
From: Nicola Salmoria <nicola.salmoria@gmail.com>
To: "Vladimir.S" <svabox@gmail.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an
        Invariant Self
Message-ID:
        <CAMZYVZgE+gLH4w=xOaLa6DDP3KW3S6rggU8V5W=
Ts93izu6T8g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Fri, May 13, 2016 at 12:55 PM, Vladimir.S <svabox@gmail.com> wrote:

> > I'm not convinced by this example.
>
> Probably my & Matthew's previous discussion in `[swift-evolution] [RFC]
> #Self` topic will help you. I was trying there to find out (in primitive
> examples) what Matthew is trying to achive with this `->StaticSelf` in
> protocol.
>
> In two words - he wants to achieve requirement 'return Self class or any
> of base classes', as current `->Self` requires 'strictly return Self
class'
>

I think I understand what the request is, but I'm not sure if it's a
problem worth solving, and if this would be the right solution.

Going back to the example, let's say you have the requested

protocol Fooable {
    func foo() -> StaticSelf
}

class A: Fooable {
    func foo() -> A { return A() }
}

class B: A {
}

How would you use foo() in generic code?

func bar<T: Fooable>(_ x: T) -> X {
    return x.foo()
}

What does bar() return? What do you put in place of X in its declaration?
You can't use T, you can't use T.StaticSelf. So what's the purpose of
having a protocol if you can't use it in generic code?

Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/f33b31ad/attachment-0001.html
>

------------------------------

Message: 15
Date: Fri, 13 May 2016 12:08:22 -0600
From: Erica Sadun <erica@ericasadun.com>
To: Brent Royal-Gordon <brent@architechies.com>, Chris Lattner
        <clattner@apple.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,
        prefix(while:), drop(while:), and iterate to the stdlib
Message-ID: <1FC733A8-6BE7-45A0-9579-841AE52B5BA9@ericasadun.com>
Content-Type: text/plain; charset="utf-8"

On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> The proposal has been updated as per feedback from the core team (
https://github.com/apple/swift-evolution/pull/275). This includes
removing some last vestiges of Swift 2 naming as well as replacing
`iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.
>
> The proposal says this:
>
> public func unfold<T, State>(_ initialState: State, applying:
State -> (T, State)?) -> UnfoldSequence<T>
> public func unfold<T>(_ initialElement: T, apply: T -> T) ->
UnfoldSequence<T>
>
> However, the comment implies that the second one should instead be this:
>
> public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
UnfoldSequence<T>
>
> I'm not sure I like having these be overloaded on only the return type
of the closure. Maybe we could do something like this?
>
> public func unfold<T, State>(fromState initialState: State,
applying: State -> (T, State)?) -> UnfoldSequence<T>
> public func unfold<T>(fromFirst initialElement: T, apply: T -> T)
-> UnfoldSequence<T>
>
> That way you're calling either `unfold(fromState:applying:)` or
`unfold(fromFirst:applying:)`. (Some further bikeshedding might be needed
here—it's late and I'm tired.)

I really don't want to see this discussion die as I have a vested interest
in getting this functionality into
Swift 3. So let me suggest that

`sequence(_:, next:) -> AdHocSequence`

might be a Swift acceptable solution. We're not going to see fold/unfold
pair happen. It's a given that
`reduce` is a fixed point in Swift space and `sequence` well describes
what this should be doing.

So is it possible to push forward with `sequence`, whose only negative
seems to be that it's not as well
loved as `unfold`?

-- Erica

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/07e13f7a/attachment-0001.html
>

------------------------------

Message: 16
Date: Fri, 13 May 2016 21:16:03 +0300
From: Pyry Jahkola <pyry.jahkola@iki.fi>
To: Erica Sadun <erica@ericasadun.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0075: Adding a Build
        Configuration Import Test
Message-ID: <95C947FC-C523-41C3-A385-44AFC469124E@iki.fi>
Content-Type: text/plain; charset="utf-8"

> On 13 May 2016, Erica Sadun wrote:
>
>> As per Pyry’s feedback, you could add a version:
>>
>> #if import Frobnication(<1.7.3) // <- Only added version constraint
here.
>> extension Knob : Frobnicatable { ... }
>> #endif
>
> I have no problem with this but would need to defer to the build and
language people to determine whether that's practical in today's Swift.
Right now, there's a major-version mention in build packages but I'm not
sure whether that information then propagates in a usable way. If it's
possible, then yes, I'd rather add it in the initial design than as a later
addition and I can extend Pyry's suggestion in "Future Directions".

I already gave my +1 on the original proposal and if `canImport` is indeed
easiest to implement we should get it going now.

The `#if import Foo` blocks and conditional imports with version checks
can easily be added at a later time without much complication or breakage,
AFAICT. Good if you can include those in the "Future Directions" section.

> p.s. Also on my Swift Bucket list: "import as".

Splendid! I'd already forgotten about qualified imports and renaming!
Those would be welcome additions too.

— Pyry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/9e170f04/attachment-0001.html
>

------------------------------

Message: 17
Date: Fri, 13 May 2016 11:19:08 -0700
From: Max Moiseev <moiseev@apple.com>
To: swift-evolution@swift.org
Subject: [swift-evolution] [draft-proposal] allow access to the
        underlying collection of a slice
Message-ID: <D32AAB4D-D21D-428D-AE52-BF0566DD825D@apple.com>
Content-Type: text/plain; charset="utf-8"

Hi everyone!

Here is the proposal to allow access to the underlying collections of
slices. Existing API of slice types is very minimal and as such prevents
possible optimizations. Exposing the base collection via a public readonly
property will make such optimizations possible.

Max

Adding a public base property to slices

Proposal: SE-NNNN
Author(s): Max Moiseev <https://github.com/moiseev>
Status: Awaiting review
Review manager: TBD
Introduction

Slice types provided by the standard library <
https://github.com/apple/swift/blob/master/stdlib/public/core/Slice.swift.gyb>
should allow public readonly access to their base collections to make
efficient implementations of protocol requirements possible in conforming
types.

Motivation

The MutableCollection protocol conformance requires providing an
implementation of the following subscript:

subscript(bounds: Range<Index>) -> SubSequence { get set }
If the collection chooses to use one of a variety of slice types from the
standard library as its SubSequence, the default implementation of a setter
for this subscript will use the algorithm provided by the
_writeBackMutableSlice <
https://github.com/apple/swift/blob/master/stdlib/public/core/WriteBackMutableSlice.swift>
function. This approach is fine for forward collections. It is quite
possible, however, that the most efficient implementation of this setter
would be to simply call the memcpy function. Unfortunately, slice API does
not provide any way to reach to the underlying base collection, even though
reference to it is stored in an internal property.

Proposed solution

We propose to export a public readonly property base, that will enable
optimizations mentioned above. Here is how MutableRandomAccessSlice
definition would look like:

public struct MutableRandomAccessSlice<
  Base : protocol<RandomAccessIndexable, MutableIndexable>
> : RandomAccessCollection, MutableCollection {

  /// The underlying collection of the slice
  public var base: Base { get }
}
The same change is applicable to both mutable and immutable slice types.

Impact on existing code

The proposed change is purely additive and does not affect existing code.

Alternatives considered

Alternative for immutable slices would be to simply rename the already
read-only _base property to base and make it public, but this way the
change is not purely additive and might cause some damage inside the
standard library code.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/13768551/attachment-0001.html
>

------------------------------

Message: 18
Date: Fri, 13 May 2016 11:19:23 -0700
From: Joe Groff <jgroff@apple.com>
To: Erica Sadun <erica@ericasadun.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
        in parameter lists and tuples
Message-ID: <B61AB4F9-B20C-4B6E-A205-9D465ABB2C2A@apple.com>
Content-Type: text/plain; charset=utf-8

> On May 13, 2016, at 10:46 AM, Erica Sadun <erica@ericasadun.com> wrote:
>
>
>> On May 13, 2016, at 11:29 AM, Joe Groff <jgroff@apple.com> wrote:
>>
>>>
>>> On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:
>>>
>>> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>>> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:
>>>>>> You’re arguing that you want to read Swift code written like this?
>>>>>
>>>>> I wouldn't mind it.
>>>>
>>>> I personally find that style repulsive :slight_smile: and I haven’t seen swift
code commonly doing it. I’m not sure that we want to encourage it either.
>>>>
>>>
>>> No. Tell us what you *really* think of the style. Don't hold back.[1]
>>>
>>>> If we were really concerned about this, a narrower way to solve the
same problem would be to allow a comma before the ), but *only* when there
is a newline between them. I still don’t see why we’d want to encourage
this though.
>>>
>>> I wouldn't object to this restriction. I cannot think of a situation
where using ",)" -- that is the comma adjacent to a closing parenthesis --
makes sense for any reason previously enumerated in support of this
proposal.
>>
>> I don't see why we need to micromanage the situations where trailing
commas are allowed. That's just unnecessarily increasing the fractal
complexity of the language. We've delegated other style choices like
requiring `self.` or brace formatting to linters; why does this one need to
be legislated by the compiler?
>>
>> -Joe
>
> Mostly because I'm trying to play nice and get Chris to reconsider. I'd
like to get the feature, I'm willing to compromise on the technicalities.

Sorry, I replied to you, but my comments were more directed toward Chris.

-Joe

------------------------------

Message: 19
Date: Fri, 13 May 2016 12:15:38 -0600
From: Erica Sadun <erica@ericasadun.com>
To: Chris Lattner via swift-evolution <swift-evolution@swift.org>,
        alex@kempgen.de
Subject: [swift-evolution] Interspersing guard let with guard boolean
Message-ID: <A0645FEA-B666-4E3D-8DDC-8406CE86E813@ericasadun.com>
Content-Type: text/plain; charset=us-ascii

Is there a technical reason that Swift cannot be expanded to allow
arbitrary mixes of conditional binding and boolean assertions within a
single compound guard statement?

Thanks, -- E

------------------------------

Message: 20
Date: Fri, 13 May 2016 11:23:44 -0700
From: Joe Groff <jgroff@apple.com>
To: Erica Sadun <erica@ericasadun.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>,
        alex@kempgen.de
Subject: Re: [swift-evolution] Interspersing guard let with guard
        boolean
Message-ID: <2F004069-682D-4C14-B9C4-158ACA735D0F@apple.com>
Content-Type: text/plain; charset=us-ascii

> On May 13, 2016, at 11:15 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Is there a technical reason that Swift cannot be expanded to allow
arbitrary mixes of conditional binding and boolean assertions within a
single compound guard statement?

No. You already can, we just have the somewhat strange rule that to
separate `guard` conditions uses `,` before optional or pattern conditions,
but `where` before boolean conditions:

        guard x == 0,
          let y = optional where
          z == 2 {
        }

There's no technical reason we couldn't accept either 'where' or ','
consistently.

-Joe

------------------------------

Message: 21
Date: Fri, 13 May 2016 12:27:16 -0600
From: Erica Sadun <erica@ericasadun.com>
To: Joe Groff <jgroff@apple.com>, mike@mikeash.com
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>,
        alex@kempgen.de
Subject: Re: [swift-evolution] Interspersing guard let with guard
        boolean
Message-ID: <9E13E3A9-3FAC-4D14-B3E6-B0D4054069B0@ericasadun.com>
Content-Type: text/plain; charset=us-ascii

> On May 13, 2016, at 12:23 PM, Joe Groff <jgroff@apple.com> wrote:
>
>
>> On May 13, 2016, at 11:15 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> Is there a technical reason that Swift cannot be expanded to allow
arbitrary mixes of conditional binding and boolean assertions within a
single compound guard statement?
>
> No. You already can, we just have the somewhat strange rule that to
separate `guard` conditions uses `,` before optional or pattern conditions,
but `where` before boolean conditions:
>
> guard x == 0,
> let y = optional where
> z == 2 {
> }
>
> There's no technical reason we couldn't accept either 'where' or ','
consistently.
>
> -Joe

Is it worth a proposal to allow both, for when the where clauses don't
have to be semantically tied to the conditional binding?

-- E

/ccing in Mike Ash so he can gloat

------------------------------

Message: 22
Date: Fri, 13 May 2016 21:34:58 +0300
From: "Vladimir.S" <svabox@gmail.com>
To: Adrian Zubarev <adrian.zubarev@devandartist.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <66427699-ae82-5140-ac5f-7f97ce14cc4a@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hmm..

What about such synthetic scenario:

at the moment of writing our code we have:

public protocol MyProtocol {
   func foo()
}

public struct StructA:MyProtocol {
   func foo()
}

public struct StructB:MyProtocol {
   func foo()
}

and have

public protocol ExtraProtocol1 {
   func bar()
}

public protocol ExtraProtocol2 {
   func blort()
}

then we actually can have such code:

func f(p: MyProtocol) {
   if let a = p as? struct<StructA, ExtraProtocol1> {
      a.foo()
      a.bar()
   }
   else
   if let b = p as? struct<StructB, ExtraProtocol2> {
      b.foo()
      b.blort()
   }
}

as we can(as example) expect that in 3rd party code someone will do:

extension StructA: ExtraProtocol1 {
   func bar() {}
}

extension StructB: ExtraProtocol2 {
   func blort() {}
}

On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
>> 'struct<>' does seem redundant unless it becomes subtypeable. If
>> you want a struct which conforms to several protocols,
protocol<>
>> already covers this.
>>
>> I think this is not correct. Lets check this example:
>>
>> func foo(value: SomeProtocol) {
>>
>> if let a = value as? struct<StructA, SomeProtocol> { /* do
>> something with a */ }
>>
>> else if let b = value as? struct<StructB, SomeProtocol> { /* do
>> something with b */ }
>>
>> }
>>
>> In this scenario you’ll be able to access properties and functions
>> from `StructA` or `StructB` which might not be covered by
>> `SomeProtocol`. Everything is merged nicely into one instance. But
>> you are right it depends on the use-case.
>>
>>
>> There is no need to include the protocol here. Just do this:
>>
>> if let a = value as? StructA { use a }
>>
> Whoops, I forgot that this will do the trick. I apologize for any
confusion
> here, you are totally right.
>
> That been said, do we really need `type<>` aka. `all<>` for value types?
I
> need to rethink this part of the proposal. Is there any use-case where we
> would need this (any scenario for the future Swift version also counts)?
>
> If we had `all<>` in Swift already for extendable reference types and one
> day structs would become subtypeable, this wouldn’t be a huge problem to
> upgrade `all<>` for structs I guess.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

------------------------------

Message: 23
Date: Fri, 13 May 2016 11:36:55 -0700
From: Matt Wright <mww@apple.com>
To: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
        for Swift 3 naming conventions
Message-ID: <178CA219-60D2-4A43-96F3-86BA02DB7CBA@apple.com>
Content-Type: text/plain; charset=utf-8

[Apologies for the weird threading, I missed the original email to the
list so I can’t reply to it directly]

I just wanted to let the list know that I updated proposal SE-0088 to fix
the typos and include a more complete listing of the Dispatch module after
the transformations in the proposal have been applied. Additionally, I’ve
been keeping up with some of the feedback in this review thread and looking
to see which ones would be best applied to the proposal. Though it should
be made clear, this particular update only covers fixing the
inconsistencies in my original proposal and providing a more complete
overview of the module layout.

Similar to the changes in Foundation that are proposed on swift-evolution,
I don’t expect all of the changes in libdispatch will be able to go through
this process. As this is a large change (and, hopefully, a step forwards)
to libdispatch I believe it is important to bring it to the swift-evolution
list and take away your feedback for inclusion in future iterations of the
module.

Thanks again for your continued feedback,
Matt

> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
> Hello Swift community,
>
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" begins now and runs through May 17. The proposal is available
here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
>
> Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
change to Swift?
> * Does this proposal fit well with the feel and direction of
Swift?
> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a
quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

------------------------------

Message: 24
Date: Fri, 13 May 2016 14:06:23 -0500
From: Matthew Johnson <matthew@anandabits.com>
To: Nicola Salmoria <nicola.salmoria@gmail.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an
        Invariant Self
Message-ID: <6A1CC61D-1AB6-48C9-88E8-210DB4B85C89@anandabits.com>
Content-Type: text/plain; charset="utf-8"

> On May 13, 2016, at 1:11 PM, Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>
> On Fri, May 13, 2016 at 12:55 PM, Vladimir.S <svabox@gmail.com <mailto: > svabox@gmail.com>> wrote:
> > I'm not convinced by this example.
>
> Probably my & Matthew's previous discussion in `[swift-evolution] [RFC]
#Self` topic will help you. I was trying there to find out (in primitive
examples) what Matthew is trying to achive with this `->StaticSelf` in
protocol.
>
> In two words - he wants to achieve requirement 'return Self class or any
of base classes', as current `->Self` requires 'strictly return Self class'
>
> I think I understand what the request is, but I'm not sure if it's a
problem worth solving, and if this would be the right solution.
>
> Going back to the example, let's say you have the requested
>
> protocol Fooable {
> func foo() -> StaticSelf
> }
>
> class A: Fooable {
> func foo() -> A { return A() }
> }
>
> class B: A {
> }
>
> How would you use foo() in generic code?
>
> func bar<T: Fooable>(_ x: T) -> X {
> return x.foo()
> }
>
> What does bar() return? What do you put in place of X in its declaration?
> You can't use T, you can't use T.StaticSelf. So what's the purpose of
having a protocol if you can't use it in generic code?

This is a good question. Thank you very much for providing a concrete
example along with the question.

Let’s look at an example of what some of us have in mind:

protocol StringCreatable {
    static func createWithString(s: String) -> StaticSelf
}

extension NSURL: StringCreatable {
    static func createWithString(s: String) -> StaticSelf {
        // ...
    }
}

func foo<Result: StringCreatable>(s: String) -> Result {
    return Result.createWithString(s: s)
}

Obviously this will not work properly because we are not guaranteed that
`createWithString` returns Result (that is only possible if the return type
is Self). We would have to do the following:

protocol StringCreatable {
    typealias ConformingType = StaticSelf
    static func createWithString(s: String) -> StaticSelf
}

func foo<Result: StringCreatable where Result.ConformingType == Result>(s:
String) -> Result {
    return Result.createWithString(s: s)
}

This requires same type constraints. I believe that is coming as part of
“completing generics”.

However, it also raises a question: if the conformance afforded to
subclasses can’t actually be used in a useful manner they probably
shouldn’t have that conformance in the first place. If the conformance
isn’t inherited then we don’t need StaticSelf at all (we can just use Self
and still conform the visible class of a class cluster). This is the point
Joe has been making all along. Working through the example has helped me
understand this point of view better.

I wonder if anyone has any other examples where subclass conformance would
actually be useful. If so, please share. Those who are supporting this
proposal: how do you envision using StaticSelf in your code? What are some
examples where you have had trouble due to the current limitations of the
language?

-Matthew

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/faddc0a1/attachment-0001.html
>

------------------------------

Message: 25
Date: Fri, 13 May 2016 12:07:29 -0700
From: Kevin Ballard <kevin@sb.org>
To: Erica Sadun <erica@ericasadun.com>, "Brent Royal-Gordon"
        <brent@architechies.com>, Chris Lattner <clattner@apple.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,
        prefix(while:), drop(while:), and iterate to the stdlib
Message-ID:
        <1463166449.928503.607214225.00CC8144@webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"

On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution > <swift- > > evolution@swift.org> wrote:
>>
>>> The proposal has been updated as per feedback from the core team
>>> (https://github.com/apple/swift-evolution/pull/275). This includes
>>> removing some last vestiges of Swift 2 naming as well as replacing
>>> `iterate(_:apply:)` with an overloaded function
>>> `unfold(_:applying:)`.
>>
>> The proposal says this:
>>
>> public func unfold<T, State>(_ initialState: State, applying: State
>> -> (T, State)?) -> UnfoldSequence<T>
>> public func unfold<T>(_ initialElement: T, apply: T -> T) ->
>> UnfoldSequence<T>
>>
>> However, the comment implies that the second one should instead
>> be this:
>>
>> public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
>> UnfoldSequence<T>
>>
>> I'm not sure I like having these be overloaded on only the return
>> type of the closure. Maybe we could do something like this?
>>
>> public func unfold<T, State>(fromState initialState: State,
>> applying: State -> (T, State)?) -> UnfoldSequence<T>
>> public func unfold<T>(fromFirst initialElement: T, apply: T -> T) ->
>> UnfoldSequence<T>
>>
>> That way you're calling either `unfold(fromState:applying:)` or
>> `unfold(fromFirst:applying:)`. (Some further bikeshedding might be
>> needed here—it's late and I'm tired.)
>
> I really don't want to see this discussion die as I have a vested
> interest in getting this functionality into
> Swift 3. So let me suggest that
>
> `sequence(_:, next:) -> AdHocSequence`
>
> might be a Swift acceptable solution. We're not going to see
> fold/unfold pair happen. It's a given that
> `reduce` is a fixed point in Swift space and `sequence` well describes
> what this should be doing.
>
> So is it possible to push forward with `sequence`, whose only negative
> seems to be that it's not as well
> loved as `unfold`?

I do like `sequence`, though I'm not sold on the name AdHocSequence
(just from that name it's hard to figure out what it does). An
alternative is `expand`, which is nice because it pairs with `reduce`,
but it's less obvious that it produces a sequence and the name isn't as
good with the stateful version.

As for return type name, we could go ahead and use UnfoldSequence<T>
anyway even though the function isn't named `unfold`, because this name
will make sense to people who do know what unfold is, and I'm not
convinced we can have a meaningful name for people who don't (since
SequenceSequence is too silly).

So given that, I'll suggest the following:

func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T>
func sequence<T, State>(state: State, next: (inout State) -> T?) ->
UnfoldSequence<T>

I'm suggesting `sequence(initial:next:)` instead of the previously-
suggested `sequence(from:applying:)` because the term "from" could
equally well mean the first element or the state, whereas "initial"
should make it more obvious that this value is the first element of the
resulting sequence. And I'm using "next" as suggested by Erica because
the function does return the next element, and it's similar to the
IteratorProtocol method. I've also chosen to change the stateful version
to use an inout parameter, as previously suggested, because it's
equivalent to the State -> (T, State)? in functionality but is less
likely to produce unwanted COW copies.

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/6087ca3b/attachment-0001.html
>

------------------------------

Message: 26
Date: Fri, 13 May 2016 21:14:44 +0200
From: Adrian Zubarev <adrian.zubarev@devandartist.com>
To: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <etPan.573627a4.578126f6.6ab2@DevAndArtist.fritz.box>
Content-Type: text/plain; charset="utf-8"

As we can(as example) expect that in 3rd party code someone will do:

extension StructA: ExtraProtocol1 {
func bar() {}
}

extension StructB: ExtraProtocol2 {
func blort() {}
}

Can we really do that? I mean, I thought about that myself but I came to
the conclusion that this scenario is like: I was to lazy to couple this
structs to my library protocols, will you do that for me?

Sure one could think that this protocols might be optional but the `f(p:
MyProtocol)` function will cover this scenario.

Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
allow us to do is to distinguish between value and reference types for
generics. I tried this differentiation types with protocols like
`AnyReference` and `AnyValue` in another topic before (Should we rename
"class" when referring to protocol conformance?), but I kinda like this new
approach.

Here is what I mean in detail:

protocol SomeProtocol /* we can’t constraint it to value types at the
moment, only `class`es works */ {}

func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }

This function is pretty neat. (1) You can force the library user to create
a struct with conformance to `SomeProtocol`. (2) This approach will accept
any struct which conforms to that protocol.

As I said in the protocol comment above protocols can only be constrained
to classes at the moment, and this might change in the future. If we also
had some sort of things for generics so the function from above might have
looked like this:

func foo<T: struct where T: SomeProtocol>(value: T) {}

But it seems that such a thing won’t ever happen to Swift.

Basically `struct<>`, `class<>` and `enum<>` will just enable this for us.
`all<>` would accept any type at its first element.

func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>)
{ /* T could be a reference type or value type */ }

That been said, `all<>` could replace `protocol<>` where it is composed
from protocols. `all<>` can only be used as a generic constraints if the
first element is a protocol or a reference type.

@Matthew: isn’t this somehow a step towards (generic) `PureValue` types?

struct A<T> {

    var value: struct<T> // if we drop the strict rule of at least one
protocols
}

How does it sound to you?

--
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 20:34:59, Vladimir.S (svabox@gmail.com) schrieb:

Hmm..

What about such synthetic scenario:

at the moment of writing our code we have:

public protocol MyProtocol {
func foo()
}

public struct StructA:MyProtocol {
func foo()
}

public struct StructB:MyProtocol {
func foo()
}

and have

public protocol ExtraProtocol1 {
func bar()
}

public protocol ExtraProtocol2 {
func blort()
}

then we actually can have such code:

func f(p: MyProtocol) {
if let a = p as? struct<StructA, ExtraProtocol1> {
a.foo()
a.bar()
}
else
if let b = p as? struct<StructB, ExtraProtocol2> {
b.foo()
b.blort()
}
}

On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
>> 'struct<>' does seem redundant unless it becomes subtypeable. If
>> you want a struct which conforms to several protocols, protocol<>
>> already covers this.
>>
>> I think this is not correct. Lets check this example:
>>
>> func foo(value: SomeProtocol) {
>>
>> if let a = value as? struct<StructA, SomeProtocol> { /* do
>> something with a */ }
>>
>> else if let b = value as? struct<StructB, SomeProtocol> { /* do
>> something with b */ }
>>
>> }
>>
>> In this scenario you’ll be able to access properties and functions
>> from `StructA` or `StructB` which might not be covered by
>> `SomeProtocol`. Everything is merged nicely into one instance. But
>> you are right it depends on the use-case.
>>
>>
>> There is no need to include the protocol here. Just do this:
>>
>> if let a = value as? StructA { use a }
>>
> Whoops, I forgot that this will do the trick. I apologize for any
confusion
> here, you are totally right.
>
> That been said, do we really need `type<>` aka. `all<>` for value types?
I
> need to rethink this part of the proposal. Is there any use-case where we
> would need this (any scenario for the future Swift version also counts)?
>
> If we had `all<>` in Swift already for extendable reference types and one
> day structs would become subtypeable, this wouldn’t be a huge problem to
> upgrade `all<>` for structs I guess.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/167979a4/attachment-0001.html
>

------------------------------

Message: 27
Date: Fri, 13 May 2016 19:24:31 +0000
From: Jacob Bandes-Storch <jtbandes@gmail.com>
To: Matt Wright <mww@apple.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
        for Swift 3 naming conventions
Message-ID:
        <
CADcs6kNjyOgbBWs-4Ho8Mc2882DRKHJbAhOrvk1sggb-_7audA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

This looks great. Thanks for revising. I'm now a +1 on this.

A couple more minor suggestions:

- Consider renaming setTimer(...) to resetTimer() or just reset(), or
something similar?

- Consider making Semaphore's wait() throw an error, rather than returning
non-zero, in the event of a timeout. Most common uses will be "try!
wait()". Or you could have waitForever() be a separate, non-throwing
function.

Jacob Bandes-Storch

On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution < > swift-evolution@swift.org> wrote:

> [Apologies for the weird threading, I missed the original email to the
> list so I can’t reply to it directly]
>
> I just wanted to let the list know that I updated proposal SE-0088 to fix
> the typos and include a more complete listing of the Dispatch module
after
> the transformations in the proposal have been applied. Additionally, I’ve
> been keeping up with some of the feedback in this review thread and
looking
> to see which ones would be best applied to the proposal. Though it should
> be made clear, this particular update only covers fixing the
> inconsistencies in my original proposal and providing a more complete
> overview of the module layout.
>
> Similar to the changes in Foundation that are proposed on
swift-evolution,
> I don’t expect all of the changes in libdispatch will be able to go
through
> this process. As this is a large change (and, hopefully, a step forwards)
> to libdispatch I believe it is important to bring it to the
swift-evolution
> list and take away your feedback for inclusion in future iterations of
the
> module.
>
> Thanks again for your continued feedback,
> Matt
>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < > > swift-evolution@swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> conventions" begins now and runs through May 17. The proposal is
available
> here:
> >
> >
>
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to
answer
> in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant
a
> change to Swift?
> > * Does this proposal fit well with the feel and direction of
> Swift?
> > * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a
> quick reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >
https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/25063811/attachment-0001.html
>

------------------------------

Message: 28
Date: Fri, 13 May 2016 19:29:06 +0000
From: Xiaodi Wu <xiaodi.wu@gmail.com>
To: Matt Wright <mww@apple.com>, swift-evolution
        <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
        for Swift 3 naming conventions
Message-ID:
        <
CAGY80umC-paivBJ3Ci3MPp_j+Ex_QrYe7LFNmN+2TYMB4J53wQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

More nits:

setHighWater(highWater:) and its ilk should should probably be
setHighWater(_:slight_smile: and so on (I include among these setInterval(interval:),
setTargetQueue(queue:), etc.)

Similarly, in terms of conforming to Swift guidelines, I notice many
instances where labels repeat the parameter type, especially
DispatchWalltime. For instance, setTimer(walltime: DispatchWalltime,
leeway: DispatchTimeInterval)--not sure what to suggest here other than
point out that the first label is redundant.
On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution < > swift-evolution@swift.org> wrote:

> [Apologies for the weird threading, I missed the original email to the
> list so I can’t reply to it directly]
>
> I just wanted to let the list know that I updated proposal SE-0088 to fix
> the typos and include a more complete listing of the Dispatch module
after
> the transformations in the proposal have been applied. Additionally, I’ve
> been keeping up with some of the feedback in this review thread and
looking
> to see which ones would be best applied to the proposal. Though it should
> be made clear, this particular update only covers fixing the
> inconsistencies in my original proposal and providing a more complete
> overview of the module layout.
>
> Similar to the changes in Foundation that are proposed on
swift-evolution,
> I don’t expect all of the changes in libdispatch will be able to go
through
> this process. As this is a large change (and, hopefully, a step forwards)
> to libdispatch I believe it is important to bring it to the
swift-evolution
> list and take away your feedback for inclusion in future iterations of
the
> module.
>
> Thanks again for your continued feedback,
> Matt
>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < > > swift-evolution@swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> conventions" begins now and runs through May 17. The proposal is
available
> here:
> >
> >
>
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to
answer
> in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant
a
> change to Swift?
> > * Does this proposal fit well with the feel and direction of
> Swift?
> > * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a
> quick reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >
https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4644df43/attachment-0001.html
>

------------------------------

Message: 29
Date: Fri, 13 May 2016 12:44:59 -0700
From: Matt Wright <mww@apple.com>
To: Xiaodi Wu <xiaodi.wu@gmail.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
        for Swift 3 naming conventions
Message-ID: <96D2038A-FB04-47FF-B7CF-85923D50AD2A@apple.com>
Content-Type: text/plain; charset=utf-8

> On May 13, 2016, at 12:29 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> More nits:
>
> setHighWater(highWater:) and its ilk should should probably be
setHighWater(_:slight_smile: and so on (I include among these setInterval(interval:),
setTargetQueue(queue:), etc.)

I suspect setHighWater and setLowWater can probably become
setLimit(highWater:) setLimit(lowWater:). setTargetQueue ->
setTarget(queue:) seems like an obvious change but something about it
doesn’t sit particularly right with me. I will think about this further.
There were both very useful bits feedback on these names though, thank you!

> Similarly, in terms of conforming to Swift guidelines, I notice many
instances where labels repeat the parameter type, especially
DispatchWalltime. For instance, setTimer(walltime: DispatchWalltime,
leeway: DispatchTimeInterval)--not sure what to suggest here other than
point out that the first label is redundant.

setTimer() in particular has a setTimer(start:,…) and
setTimer(walltime:,…) that are distinct, perhaps the latter could be
`walltimeStart:`. While there was an earlier argument for removing Walltime
as a typed concept, we believe it is advantageous to keep different “types”
of time as separate distinct Swift types in the module.

> On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution < > swift-evolution@swift.org> wrote:
> [Apologies for the weird threading, I missed the original email to the
list so I can’t reply to it directly]
>
> I just wanted to let the list know that I updated proposal SE-0088 to
fix the typos and include a more complete listing of the Dispatch module
after the transformations in the proposal have been applied. Additionally,
I’ve been keeping up with some of the feedback in this review thread and
looking to see which ones would be best applied to the proposal. Though it
should be made clear, this particular update only covers fixing the
inconsistencies in my original proposal and providing a more complete
overview of the module layout.
>
> Similar to the changes in Foundation that are proposed on
swift-evolution, I don’t expect all of the changes in libdispatch will be
able to go through this process. As this is a large change (and, hopefully,
a step forwards) to libdispatch I believe it is important to bring it to
the swift-evolution list and take away your feedback for inclusion in
future iterations of the module.
>
> Thanks again for your continued feedback,
> Matt
>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" begins now and runs through May 17. The proposal is available
here:
> >
> >
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant
a change to Swift?
> > * Does this proposal fit well with the feel and direction of
Swift?
> > * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a
quick reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >
https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

------------------------------

Message: 30
Date: Fri, 13 May 2016 12:51:34 -0700
From: Matt Wright <mww@apple.com>
To: Jacob Bandes-Storch <jtbandes@gmail.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
        for Swift 3 naming conventions
Message-ID: <82629D20-E9E7-4B06-8E13-3ADBDB225099@apple.com>
Content-Type: text/plain; charset=utf-8

> On May 13, 2016, at 12:24 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
>
> This looks great. Thanks for revising. I'm now a +1 on this.
>
> A couple more minor suggestions:
>
> - Consider renaming setTimer(...) to resetTimer() or just reset(), or
something similar?

setTimer addresses both the initial setup as well as setting it again. I’m
not sure reset is a good name for it.

> - Consider making Semaphore's wait() throw an error, rather than
returning non-zero, in the event of a timeout. Most common uses will be
"try! wait()". Or you could have waitForever() be a separate, non-throwing
function.

Throwing an error here seems like a sensible improvement.

>
> Jacob Bandes-Storch
>
> On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution < > swift-evolution@swift.org> wrote:
> [Apologies for the weird threading, I missed the original email to the
list so I can’t reply to it directly]
>
> I just wanted to let the list know that I updated proposal SE-0088 to
fix the typos and include a more complete listing of the Dispatch module
after the transformations in the proposal have been applied. Additionally,
I’ve been keeping up with some of the feedback in this review thread and
looking to see which ones would be best applied to the proposal. Though it
should be made clear, this particular update only covers fixing the
inconsistencies in my original proposal and providing a more complete
overview of the module layout.
>
> Similar to the changes in Foundation that are proposed on
swift-evolution, I don’t expect all of the changes in libdispatch will be
able to go through this process. As this is a large change (and, hopefully,
a step forwards) to libdispatch I believe it is important to bring it to
the swift-evolution list and take away your feedback for inclusion in
future iterations of the module.
>
> Thanks again for your continued feedback,
> Matt
>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" begins now and runs through May 17. The proposal is available
here:
> >
> >
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant
a change to Swift?
> > * Does this proposal fit well with the feel and direction of
Swift?
> > * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a
quick reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >
https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

------------------------------

Message: 31
Date: Fri, 13 May 2016 16:58:06 -0300
From: Leonardo Pessoa <me@lmpessoa.com>
To: Swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Could enums have their rawValue type
        inferred?
Message-ID:
        <
CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Eric, I think I understood your proposal. If I may explain in other words
it would be "to automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value", am I right? I
think this would imply a little more inference and type checking rules from
the compiler and maybe even take a little longer to fully compile code. I'm
not sure it's feasible but from your examples, I can see how it enhances
readability of the code, so I'm +1 for it. My only concern is that you
would still need to fully declare the enum's name where the value of the
enum is used. Taking from your own example

    Animate.fadeIn(view, withSpeed: .fast)

couldn't be called that way if withSpeed expects and NSTimeInterval because
the compiler won't know whether you're refering to transitionSpeed or to
ambientAnimationSpeed. You would still have to call it like

    Animate.fadeIn(view, withSpeed: transitionSpeed.fast)

even if you had only one possible enum value over all declared enums
because that would still force the compiler to search for each value over
all known enums to define where the value you're using comes from and make
sure there are no two enums with the same value.

Aside from that, I good with the idea.

On 13 May 2016 at 15:09, Eric Miller via swift-evolution < > swift-evolution@swift.org> wrote:

> This might open a larger can of worms than I imagine, but what do you
> folks think about using the `rawValue` of an enum when that rawValue is a
> fit for the expected type?
>
> Use case.
>
> I'm making an animation facade, and it has some speed presets:
>
> class Animate {
> enum transitionSpeed: NSTimeInterval {
> case fast = 0.15
> case slow = 0.5
> }
> enum ambientAnimationSpeed: NSTimeInterval {
> case fast = 1.0
> case slow = 5.0
> }
> ...
> }
>
> I did them with static variables at first but that made the call site
> verbose. Compare:
>
> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
> Animate.fadeIn(view, withSpeed: .fast)
>
> So, I like the enum approach better, but my library code has to use
> `rawValue` to do anything with the actual value, of course:
>
> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
> .fast) {
> ...
> UIView.animateWithDuration(duration.rawValue, animations: { })
> }
>
> It's not a serious issue, but the code is more clear and beautiful if it
> has just myIntent, rather than myIntent.rawValue.
>
> I've hit this issue when modeling other things, such as:
>
> * server fault codes
> * HTTP status codes
> * Currency codes
> * Days of the week
>
> Would it be appropriate to "autocast" to the rawValue of the enum when
the
> rawValue's Type matches the type expectation of the API? Or would this
> introduce a bunch of type system uncertainty?
>
> Maybe this could be implemented as a protocol? It feels almost like the
> convenience of `CustomStringConvertible`'s `description` property.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/05a1d4c2/attachment-0001.html
>

------------------------------

Message: 32
Date: Fri, 13 May 2016 13:02:44 -0700
From: Jacob Bandes-Storch <jtbandes@gmail.com>
To: Erica Sadun <erica@ericasadun.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures
Message-ID:
        <CADcs6kPHDONJd_1zVkrEuLBJUT8QsxU_kDcdY=
hDf6EVOvEvnw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

+1, seems logical to me:

    let x: [T] = []
    let x: [T:U] = [:]
    let x: T->() = {}

Jacob

On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution < > > swift-evolution@swift.org> wrote:
> >
> >
> >> +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
> >>
> >> let _: () -> () = {}
> >> let _: (Int) -> () = {}
> >> let _: (Int, Int) -> Int = { 5 }
> >> let _: (Int, Int) -> Int = { $0 }
> >> let _: (Int, Int) -> Int = { $1 }
> >
> > +1. This would be excellent.
>
> +1. Good riddance to bad code baggage.
>
> -- E
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/1fc15c26/attachment-0001.html
>

------------------------------

Message: 33
Date: Fri, 13 May 2016 15:06:18 -0500
From: Matthew Johnson <matthew@anandabits.com>
To: Jacob Bandes-Storch <jtbandes@gmail.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures
Message-ID: <5F3F407C-B624-4596-9850-C8E059D5EE9A@anandabits.com>
Content-Type: text/plain; charset="utf-8"

Is anyone planning to write a proposal for this?

Sent from my iPhone

> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
>
> +1, seems logical to me:
>
> let x: [T] = []
> let x: [T:U] = [:]
> let x: T->() = {}
>
> Jacob
>
>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
>> >
>> >
>> >> +1. In general, I think we should allow implicit arguments, without
requiring the closure to use all the implicit $n variables like we do
today. These should all be valid:
>> >>
>> >> let _: () -> () = {}
>> >> let _: (Int) -> () = {}
>> >> let _: (Int, Int) -> Int = { 5 }
>> >> let _: (Int, Int) -> Int = { $0 }
>> >> let _: (Int, Int) -> Int = { $1 }
>> >
>> > +1. This would be excellent.
>>
>> +1. Good riddance to bad code baggage.
>>
>> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/edf1fd63/attachment-0001.html
>

------------------------------

Message: 34
Date: Fri, 13 May 2016 13:12:10 -0700
From: Joe Groff <jgroff@apple.com>
To: Matthew Johnson <matthew@anandabits.com>
Cc: Matthew Johnson via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an
        Invariant Self
Message-ID: <DA7FECEA-2E3D-45D9-BE6A-E95C859F5794@apple.com>
Content-Type: text/plain; charset=us-ascii

> On May 13, 2016, at 9:06 AM, Matthew Johnson <matthew@anandabits.com> > wrote:
>
>
>> On May 13, 2016, at 10:55 AM, Joe Groff <jgroff@apple.com> wrote:
>>
>>
>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <matthew@anandabits.com> > wrote:
>>>
>>> When I write a class Base with non-final methods that return instances
of Base I can choose whether to state the return type as Self (covariant)
or Base (invariant, under this proposal StaticSelf would also be an
alternative way to state this). If I choose to specify Base as the return
type derived classes *may* override the method but are not required to.
Further, if they *do* override the method they are allowed to choose
whether their implementation returns Base or Derived.
>>
>> `StaticSelf` requirements by themselves don't even save you from
covariance. If Base conforms to a protocol (with Self == Base), Derived
inherits that conformance and also conforms (with Self == Derived). If
`StaticSelf` always refers to the conforming type, then it must also be
bindable to Base and Derived, so a base class must still use a
covariant-returning method to satisfy the `StaticSelf` requirement.
>
> We are specifying that `StaticSelf` refers to the type that explicitly
declares conformance. If a class inherits conformance it refers to the
base class which explicitly declared the conformance it is inheriting.

That makes `StaticSelf` tricky to use in generic code. This would be
invalid:

protocol Makable {
        static func make(value: Int) -> StaticSelf
}

func makeWithZero<T: Fooable>(x: Int) -> T {
        return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype
of T so isn't convertible to T
}

`StaticSelf` in this model is effectively an associated type of the
protocol, with a `Self: StaticSelf` constraint (if that were supported).

-Joe

------------------------------

Message: 35
Date: Fri, 13 May 2016 13:16:31 -0700
From: Joe Groff <jgroff@apple.com>
To: Matthew Johnson <matthew@anandabits.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures
Message-ID: <4D375D91-F148-4B2A-9E14-DE8FBBC41384@apple.com>
Content-Type: text/plain; charset=us-ascii

> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Is anyone planning to write a proposal for this?

Sounds like you just signed up!

-Joe

> Sent from my iPhone
>
> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> +1, seems logical to me:
>>
>> let x: [T] = []
>> let x: [T:U] = [:]
>> let x: T->() = {}
>>
>> Jacob
>>
>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
>> >
>> >
>> >> +1. In general, I think we should allow implicit arguments, without
requiring the closure to use all the implicit $n variables like we do
today. These should all be valid:
>> >>
>> >> let _: () -> () = {}
>> >> let _: (Int) -> () = {}
>> >> let _: (Int, Int) -> Int = { 5 }
>> >> let _: (Int, Int) -> Int = { $0 }
>> >> let _: (Int, Int) -> Int = { $1 }
>> >
>> > +1. This would be excellent.
>>
>> +1. Good riddance to bad code baggage.
>>
>> -- 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

------------------------------

Message: 36
Date: Fri, 13 May 2016 17:07:44 -0400
From: John Siracusa <siracusa@gmail.com>
To: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
        in parameter lists and tuples
Message-ID:
        <CAJu6bqtOxv6FFoZVuynvJjTdzQimv+gSc9ZNDJZWOjwzGKvd=
A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Having used, more or less continuously for my 20 years as a professional
programmer, both a language that allows trailing commas and one that does
not, I come down pretty strongly on the side of allowing trailing commas
(for all the reasons already stated in this thread). If it means requiring
a newline after the last comma to make some people feel better about it, so
be it.

-John

On Fri, May 13, 2016 at 1:46 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

>
> On May 13, 2016, at 11:29 AM, Joe Groff <jgroff@apple.com> wrote:
>
>
> On May 13, 2016, at 7:04 AM, Erica Sadun <erica@ericasadun.com> wrote:
>
> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution < > > swift-evolution@swift.org> wrote:
>
> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:
>
> You’re arguing that you want to read Swift code written like this?
>
>
> I wouldn't mind it.
>
>
> I personally find that style repulsive :slight_smile: and I haven’t seen swift code
> commonly doing it. I’m not sure that we want to encourage it either.
>
>
> No. Tell us what you *really* think of the style. Don't hold back.[1]
>
> If we were really concerned about this, a narrower way to solve the same
> problem would be to allow a comma before the ), but *only* when there is
a
> newline between them. I still don’t see why we’d want to encourage this
> though.
>
>
> I wouldn't object to this restriction. I cannot think of a situation
where
> using ",)" -- that is the comma adjacent to a closing parenthesis --
makes
> sense for any reason previously enumerated in support of this proposal.
>
>
> I don't see why we need to micromanage the situations where trailing
> commas are allowed. That's just unnecessarily increasing the fractal
> complexity of the language. We've delegated other style choices like
> requiring `self.` or brace formatting to linters; why does this one need
to
> be legislated by the compiler?
>
> -Joe
>
>
> Mostly because I'm trying to play nice and get Chris to reconsider. I'd
> like to get the feature, I'm willing to compromise on the technicalities.
> Having it would make my coding life significantly easier and if a little
> micromanagement is involved, I'm not terribly fussed. When I need
trailing
> commas, it's always at the ends of lines anyway.
>
> But since I don't want to undercut you, so I'd much prefer to step back
> and defer to your judgement on this.
>
> -- E
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/ef8148fe/attachment-0001.html
>

------------------------------

Message: 37
Date: Sat, 14 May 2016 00:16:16 +0300
From: "Vladimir.S" <svabox@gmail.com>
To: Adrian Zubarev <adrian.zubarev@devandartist.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <e4a00c9d-d327-1015-ab01-0ac4a689a114@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

You asked for any example, I give it to you :wink:
(as I said, it is syntactical, just to show that such struct<> can be used
to test some struct for conforming to protocol, that was not conformed at
writing time)
Probably we can invent useful examples for this struct<> - but I don't
believe it will be introduced in Swift :wink:

On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:
> Can we really do that? I mean, I thought about that myself but I came to
> the conclusion that this scenario is like: I was to lazy to couple this
> structs to my library protocols, will you do that for me?

------------------------------

Message: 38
Date: Sat, 14 May 2016 00:46:23 +0300
From: "Vladimir.S" <svabox@gmail.com>
To: Joe Groff <jgroff@apple.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an
        Invariant Self
Message-ID: <cbc94f19-4c47-3859-fc27-05116dec50ae@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Seems like ->StaticSelf can actually only means returns the class for which
protocol conformance was applied first(in hierarchy). I.e. some
`->BaseSelf`.
But in this case we need a method to get this 'base' class from protocol..

something like(just pseudo code!):

func makeWithZero<T: Makable >(x: Int) -> Makable(T).FirstConformedClass {
        return T.make(value: 0)
}

or

func makeWithZero<T: Makable >(x: Int) -> type<T.make(value:)> {
        return T.make(value: 0)
}

I don't know if all of this makes sense at all :wink:

On 13.05.2016 23:12, Joe Groff via swift-evolution wrote:
>
>> On May 13, 2016, at 9:06 AM, Matthew Johnson <matthew@anandabits.com> > wrote:
>>
>>
>>> On May 13, 2016, at 10:55 AM, Joe Groff <jgroff@apple.com> wrote:
>>>
>>>
>>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <matthew@anandabits.com> > wrote:
>>>>
>>>> When I write a class Base with non-final methods that return
instances of Base I can choose whether to state the return type as Self
(covariant) or Base (invariant, under this proposal StaticSelf would also
be an alternative way to state this). If I choose to specify Base as the
return type derived classes *may* override the method but are not required
to. Further, if they *do* override the method they are allowed to choose
whether their implementation returns Base or Derived.
>>>
>>> `StaticSelf` requirements by themselves don't even save you from
covariance. If Base conforms to a protocol (with Self == Base), Derived
inherits that conformance and also conforms (with Self == Derived). If
`StaticSelf` always refers to the conforming type, then it must also be
bindable to Base and Derived, so a base class must still use a
covariant-returning method to satisfy the `StaticSelf` requirement.
>>
>> We are specifying that `StaticSelf` refers to the type that explicitly
declares conformance. If a class inherits conformance it refers to the
base class which explicitly declared the conformance it is inheriting.
>
> That makes `StaticSelf` tricky to use in generic code. This would be
invalid:
>
> protocol Makable {
> static func make(value: Int) -> StaticSelf
> }
>
> func makeWithZero<T: Fooable>(x: Int) -> T {
> return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype
of T so isn't convertible to T
> }
>
> `StaticSelf` in this model is effectively an associated type of the
protocol, with a `Self: StaticSelf` constraint (if that were supported).
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

------------------------------

Message: 39
Date: Fri, 13 May 2016 17:21:02 -0500
From: Matthew Johnson <matthew@anandabits.com>
To: Joe Groff <jgroff@apple.com>
Cc: Chris Lattner via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures
Message-ID: <86DB53E1-6567-411B-8350-5C9794EEF39E@anandabits.com>
Content-Type: text/plain; charset=us-ascii

Sent from my iPhone

> On May 13, 2016, at 3:16 PM, Joe Groff <jgroff@apple.com> wrote:
>
>
>> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> Is anyone planning to write a proposal for this?
>
> Sounds like you just signed up!

Lol, sounds good. Just don't want to duplicate efforts! :slight_smile:

>
> -Joe
>
>> Sent from my iPhone
>>
>>> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>> +1, seems logical to me:
>>>
>>> let x: [T] = []
>>> let x: [T:U] = [:]
>>> let x: T->() = {}
>>>
>>> Jacob
>>>
>>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>>>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
>>>>
>>>>
>>>>> +1. In general, I think we should allow implicit arguments, without
requiring the closure to use all the implicit $n variables like we do
today. These should all be valid:
>>>>>
>>>>> let _: () -> () = {}
>>>>> let _: (Int) -> () = {}
>>>>> let _: (Int, Int) -> Int = { 5 }
>>>>> let _: (Int, Int) -> Int = { $0 }
>>>>> let _: (Int, Int) -> Int = { $1 }
>>>>
>>>> +1. This would be excellent.
>>>
>>> +1. Good riddance to bad code baggage.
>>>
>>> -- 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
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

------------------------------

Message: 40
Date: Fri, 13 May 2016 16:46:31 -0700
From: Matt Wright <mww@apple.com>
To: plx <plxswift@icloud.com>
Cc: "swift-evolution@swift.org" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
        for Swift 3 naming conventions
Message-ID: <7662E01E-8594-45E2-8ABE-2B9B22DA99F5@apple.com>
Content-Type: text/plain; charset=utf-8

> On May 13, 2016, at 9:29 AM, plx via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> * What is your evaluation of the proposal?
>
> +1 conceptually, some quibbles.
>
> I agree with a few others that `synchronously` and `asynchronously`
aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync`
or `performSynchronously`) all seem more-appropriate.
>
> I understand the impetus behind having fewer core methods, but IMHO the
`dispatch_barrier_sync` and `dispatch_barrier_async` calls ought to have
direct equivalents here (even if they are just sodlib-supplied conveniences
that call through to the unified method).

I don’t see having barrier as separate methods as a particularly good fit
for Swift. Given that there are other options surrounding how a block
operates when it is executed, it makes more sense as default parameters to
the same methods. This avoids having to have variants of the block
submission methods for both barrier, QoS, both, etc.

>
> I also don’t see `dispatch_apply` here anywhere; intentional? Ideally
it’d be @noescape, but handling `throw` / `rethrow` for that function in
this case seems complicated.

This is here in the updated version, though I agree it’s not simple to
handle throwing out of the block as multiple threads are executing the same
code at once.

>
> This next one is subjective, but I find the placement of the
group-related methods somewhat backwards vis-a-vis how I think of them in
terms of the C-API.

I suspect this can go either way but the block is still being executed on
a given queue, you’re just associating the execution of that block with a
given group. In my mind that lives on the queue, as the execution will
still occur there. Contrasting this to notify, which requests that the
group itself submits the notify block to the queue when the group itself is
empty.

>
> EG: I think of `dispatch_group_async` as a “method” on a
`dispatch_group`, so would’ve expected this:
>
> class DispatchGroup : DispatchObject {
>
> // (actual name should match chosen name convention)
> func asynchronouslyDispatch(to queue: DispatchQueue, work:
@convention(block) () -> Void)
>
> // (actual name should match chosen name convention)
> func notify(on queue: DispatchQueue, using block: @convention(block) ()
-> Void)
>
> }
>
> …(and presumably the API would have manual enter/leave/wait methods and
so on exposed).
>
> I don’t feel strongly here but bring it up in case others feel similarly.
>
> I’m a little confused about the `DispatchSpecificKey<T>` class; is it
anything more than a way to "smuggle in” a generic type parameter for the
associated value?

I think it’s a little stronger than “smuggle in” here, it allows the
compiler to enforce that you have the same type going into setSpecific that
you get out of getSpecific (or DispatchQueue.getSpecific) for a given key.
The C API here forces you to cast away from void* and I think this is a
good example of how the Swift equivalent API is helping make things safer.

>
> Also on queue-specifics, what is our expected story if we have custom
destructors? Subclass `DispatchSpecificKey`?

The value supplied to setSpecific is boxed inside a class that’s then
retained. When the queue is deallocated, or the value is replaced then the
box is released and normal Swift semantics for memory management will kick
in on your boxed value. That way the API is still flexible enough to
consume non-objects, like Ints, but also capable of taking references to
classes too.

>
> For things like `Int` specifics, I assume this API is storing auto-boxed
values…? Is there any way to side-step if we use want to store an unsafe
pointer? It’s not a big deal for me if we can’t under this API, TBH, but
I’d at least like to see this API’s implementation and costs spelled-out
more explicitly.
>
> For `DispatchData`, is there a principled reason there isn’t something
like this defined:
>
> struct DispatchDataSegment {
> let bytes: UnsafeBufferPointer<UInt8>
> let byteIndex: Int
> }
>
> extension DispatchData {
>
> /// Returns a sequence that enumerates the contiguous chunks,
> /// e.g. a sequence with elements of type `DispatchDataSegment`.
> ///
> /// Sequence-based eplacement-for `enumerateBytes(_:)`
> var segmentSequence: DispatchDataSegmentSequence { get }
>
> }

This is a good path to investigate in future improvements here.

>
> …or something analogous (instead of the proposed use
dispatch_data_apply?)?
>
> I don’t see any API yet for setting target queues, or getting queue
labels. I know the proposal isn’t documenting the APIs in full but it’s
hard to evaluate in that absence.
>
> I don’t see basic API on dispatch sources yet for things like setting
event handlers, (etc.); again I know the APIs aren’t fully specified here
but it’s hard to evaluate something that’s not fully specified.

These should be present in today’s updated module listing.

>
>
>> * Is the problem being addressed significant enough to warrant a
change to Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
>>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Chris Lattner
>> Review Manager
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

------------------------------

Message: 41
Date: Sat, 14 May 2016 01:50:37 +0200
From: Adrian Zubarev <adrian.zubarev@devandartist.com>
To: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <etPan.5736684d.50456560.6ab2@DevAndArtist.fritz.box>
Content-Type: text/plain; charset="utf-8"

If anyone is interested, I started a draft proposal with detailed design
here:
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-merging-types-with-protocols.md

I didn’t post it here, because it is a bit huge and could lose its
markdown formats. `all<>` is always bold, because this is what we are
interested in, but I provided all possible combinations if the other
formats would exists (at least all combinations I could think of, anything
else is derived from these).

`class<>` etc. can be seen as a future direction (I would say), otherwise
this would easily become out of scope for Swift 3. (I will move `class<>`
etc. from detailed design to future direction later.)

I’d love to hear your feedback and strong arguments for the motivation
part I could include into this proposal.

--
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 23:16:20, Vladimir.S (svabox@gmail.com) schrieb:

You asked for any example, I give it to you :wink:
(as I said, it is syntactical, just to show that such struct<> can be used
to test some struct for conforming to protocol, that was not conformed at
writing time)
Probably we can invent useful examples for this struct<> - but I don't
believe it will be introduced in Swift :wink:

On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:
> Can we really do that? I mean, I thought about that myself but I came to
> the conclusion that this scenario is like: I was to lazy to couple this
> structs to my library protocols, will you do that for me?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/8100916d/attachment-0001.html
>

------------------------------

Message: 42
Date: Fri, 13 May 2016 19:16:50 -0500
From: Matthew Johnson <matthew@anandabits.com>
To: Adrian Zubarev <adrian.zubarev@devandartist.com>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID: <99488013-D61B-4CD2-9671-3848838FCC8C@anandabits.com>
Content-Type: text/plain; charset="utf-8"

> On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> As we can(as example) expect that in 3rd party code someone will do:
>>
>> extension StructA: ExtraProtocol1 {
>> func bar() {}
>> }
>>
>> extension StructB: ExtraProtocol2 {
>> func blort() {}
>> }
>
>
> Can we really do that? I mean, I thought about that myself but I came to
the conclusion that this scenario is like: I was to lazy to couple this
structs to my library protocols, will you do that for me?
>
> Sure one could think that this protocols might be optional but the `f(p:
MyProtocol)` function will cover this scenario.
>
> Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
allow us to do is to distinguish between value and reference types for
generics. I tried this differentiation types with protocols like
`AnyReference` and `AnyValue` in another topic before (Should we rename
"class" when referring to protocol conformance? <
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html>),
but I kinda like this new approach.
>
> Here is what I mean in detail:
>
> protocol SomeProtocol /* we can’t constraint it to value types at the
moment, only `class`es works */ {}
>
> func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }
>
> This function is pretty neat. (1) You can force the library user to
create a struct with conformance to `SomeProtocol`. (2) This approach will
accept any struct which conforms to that protocol.
>
> As I said in the protocol comment above protocols can only be
constrained to classes at the moment, and this might change in the future.
If we also had some sort of things for generics so the function from above
might have looked like this:
>
> func foo<T: struct where T: SomeProtocol>(value: T) {}
>
> But it seems that such a thing won’t ever happen to Swift.
>
> Basically `struct<>`, `class<>` and `enum<>` will just enable this for
us. `all<>` would accept any type at its first element.
>
> func foo<T /* add more constraints here */ >(value: all<T,
>) { /* T could be a reference type or value type */ }
>
> That been said, `all<>` could replace `protocol<>` where it is composed
from protocols. `all<>` can only be used as a generic constraints if the
first element is a protocol or a reference type.
>
> @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?

No. These say nothing about semantics. PureValue is all about the
semantics of a type and has nothing to do with what mechanism is used to
implement the type.

>
> struct A<T> {
>
> var value: struct<T> // if we drop the strict rule of at least one
protocols
> }
>
> How does it sound to you?
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 13. Mai 2016 bei 20:34:59, Vladimir.S (svabox@gmail.com <mailto:
svabox@gmail.com>) schrieb:
>
>> Hmm..
>>
>> What about such synthetic scenario:
>>
>> at the moment of writing our code we have:
>>
>> public protocol MyProtocol {
>> func foo()
>> }
>>
>> public struct StructA:MyProtocol {
>> func foo()
>> }
>>
>> public struct StructB:MyProtocol {
>> func foo()
>> }
>>
>> and have
>>
>> public protocol ExtraProtocol1 {
>> func bar()
>> }
>>
>> public protocol ExtraProtocol2 {
>> func blort()
>> }
>>
>> then we actually can have such code:
>>
>> func f(p: MyProtocol) {
>> if let a = p as? struct<StructA, ExtraProtocol1> {
>> a.foo()
>> a.bar()
>> }
>> else
>> if let b = p as? struct<StructB, ExtraProtocol2> {
>> b.foo()
>> b.blort()
>> }
>> }
>>
>>
>>
>>
>> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
>> >> 'struct<>' does seem redundant unless it becomes subtypeable. If
>> >> you want a struct which conforms to several protocols, protocol<>
>> >> already covers this.
>> >>
>> >> I think this is not correct. Lets check this example:
>> >>
>> >> func foo(value: SomeProtocol) {
>> >>
>> >> if let a = value as? struct<StructA, SomeProtocol> { /* do
>> >> something with a */ }
>> >>
>> >> else if let b = value as? struct<StructB, SomeProtocol> { /* do
>> >> something with b */ }
>> >>
>> >> }
>> >>
>> >> In this scenario you’ll be able to access properties and functions
>> >> from `StructA` or `StructB` which might not be covered by
>> >> `SomeProtocol`. Everything is merged nicely into one instance. But
>> >> you are right it depends on the use-case.
>> >>
>> >>
>> >> There is no need to include the protocol here. Just do this:
>> >>
>> >> if let a = value as? StructA { use a }
>> >>
>> > Whoops, I forgot that this will do the trick. I apologize for any
confusion
>> > here, you are totally right.
>> >
>> > That been said, do we really need `type<>` aka. `all<>` for value
types? I
>> > need to rethink this part of the proposal. Is there any use-case
where we
>> > would need this (any scenario for the future Swift version also
counts)?
>> >
>> > If we had `all<>` in Swift already for extendable reference types and
one
>> > day structs would become subtypeable, this wouldn’t be a huge problem
to
>> > upgrade `all<>` for structs I guess.
>> >
>> > --
>> > Adrian Zubarev
>> > Sent with Airmail
>> >
>> >
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <
https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/0d832263/attachment-0001.html
>

------------------------------

Message: 43
Date: Fri, 13 May 2016 19:33:04 -0500
From: Matthew Johnson <matthew@anandabits.com>
To: Joe Groff <jgroff@apple.com>
Cc: Matthew Johnson via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an
        Invariant Self
Message-ID: <E5E5D42D-5E98-4FD0-A29A-A4F228B4D558@anandabits.com>
Content-Type: text/plain; charset="utf-8"

> On May 13, 2016, at 3:12 PM, Joe Groff <jgroff@apple.com> wrote:
>
>>
>> On May 13, 2016, at 9:06 AM, Matthew Johnson <matthew@anandabits.com> > wrote:
>>
>>
>>> On May 13, 2016, at 10:55 AM, Joe Groff <jgroff@apple.com> wrote:
>>>
>>>
>>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <matthew@anandabits.com> > wrote:
>>>>
>>>> When I write a class Base with non-final methods that return
instances of Base I can choose whether to state the return type as Self
(covariant) or Base (invariant, under this proposal StaticSelf would also
be an alternative way to state this). If I choose to specify Base as the
return type derived classes *may* override the method but are not required
to. Further, if they *do* override the method they are allowed to choose
whether their implementation returns Base or Derived.
>>>
>>> `StaticSelf` requirements by themselves don't even save you from
covariance. If Base conforms to a protocol (with Self == Base), Derived
inherits that conformance and also conforms (with Self == Derived). If
`StaticSelf` always refers to the conforming type, then it must also be
bindable to Base and Derived, so a base class must still use a
covariant-returning method to satisfy the `StaticSelf` requirement.
>>
>> We are specifying that `StaticSelf` refers to the type that explicitly
declares conformance. If a class inherits conformance it refers to the
base class which explicitly declared the conformance it is inheriting.
>
> That makes `StaticSelf` tricky to use in generic code. This would be
invalid:
>
> protocol Makable {
> static func make(value: Int) -> StaticSelf
> }
>
> func makeWithZero<T: Fooable>(x: Int) -> T {
> return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype
of T so isn't convertible to T
> }

I agree it’s a bit tricky. But that’s better than not possible at all.
You just need a typealias and a same type constraint to make this work as
expected / desired:

protocol Makable {
        typealias RootMakable = StaticSelf
        static func make(value: Int) -> StaticSelf
}

func makeWithZero<T: Makable where T == T.RootMakable>(x: Int) -> T {
        return T.make(value: 0) // works now
}

Now that we have a typealias we can refer to the binding of StaticSelf and
constrain it as necessary for whatever purpose we have in mind. In some
cases that will be a same type constraint so that our code works properly
with class clusters. I don’t have concrete examples of other use cases but
can imagine use cases constraining the typealias to a protocol, for example.

If we had control over inheritance of conformance at the point of
conformance we probably wouldn’t be talking about StaticSelf. But we don’t
and this is a problem that has caused enough people trouble that it is
worth solving. StaticSelf does that in a general way that is also as a
shorthand in types themselves and has consistent semantics in both use
cases.

IIRC the design of point-of-conformance control over inheritance of
conformance is pretty thorny. I wouldn’t mind seeing that feature
eventually but don’t have any confidence that it will come soon.

>
> `StaticSelf` in this model is effectively an associated type of the
protocol, with a `Self: StaticSelf` constraint (if that were supported).

If you add that the associated type is automatically bound with the
initial conformance (and cannot be modified by subclass conformances) then
yes, you can look at it this way.

>
> -Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/3276330a/attachment-0001.html
>

------------------------------

Message: 44
Date: Fri, 13 May 2016 21:06:11 -0700
From: Austin Zheng <austinzheng@gmail.com>
To: Matthew Johnson <matthew@anandabits.com>
Cc: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
        together with type<Type, Protocol, ...>
Message-ID:
        <
CANGnqV14+BLVHx7CZgoHfTKnQfpxDXFzp4mTWO4MFCFtZfKCAg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

This is certainly a detailed and well-considered proposal.

I don't think the struct functionality makes much sense. There are two ways
you can use the struct<...> construct:

1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the
struct<...> representation is unnecessary; the protocols that are available
to the user are known at compile-time, and structs can't have subtypes that
conform to additional protocols like classes can. There is an example
marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func
boo(value: SomeStruct)"; my question is why having more than two ways to
express the same idea makes the language better, easier to use, etc.

2. struct<T, Protocol1, Protocol2>. In this case struct<...> is being used
as an add-on to the generics system to denote a 'must be value type'
constraint. However, I think a 'T : class'-like 'struct' constraint makes
more sense, both because it fits better with the existing 'class'
constraint and because it can be used anywhere the generic system allows a
type parameter to be constrained. A generic 'struct' constraint would give
the currently generics system as much expressive power as struct<...>.

Overall, rather than having this be a separate feature I think it should be
developed as part of the "Generalized Existentials" feature that is already
on the roadmap for Swift 3. The cases where adding class<...>, struct<...>,
etc can improve expressive power are covered by allowing variables to take
existential types with constraints. The one big feature that Generalized
Existentials should absorb from this proposal is allowing the
representation of a concrete class type with protocol constraints
(<MyClass, SomeProtocol, AnotherProtocol>).

Best,
Austin

On Fri, May 13, 2016 at 5:16 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:

>
> On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution < > > swift-evolution@swift.org> wrote:
>
> As we can(as example) expect that in 3rd party code someone will do:
>
> extension StructA: ExtraProtocol1 {
> func bar() {}
> }
>
> extension StructB: ExtraProtocol2 {
> func blort() {}
> }
>
>
> Can we really do that? I mean, I thought about that myself but I came to
> the conclusion that this scenario is like: I was to lazy to couple this
> structs to my library protocols, will you do that for me?
>
> Sure one could think that this protocols might be optional but the `f(p:
> MyProtocol)` function will cover this scenario.
>
> Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
> allow us to do is to distinguish between value and reference types for
> generics. I tried this differentiation types with protocols like
> `AnyReference` and `AnyValue` in another topic before (Should we rename
> "class" when referring to protocol conformance?
> <
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html
>),
> but I kinda like this new approach.
>
> Here is what I mean in detail:
>
> protocol SomeProtocol /* we can’t constraint it to value types at the
> moment, only `class`es works */ {}
>
> func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }
>
> This function is pretty neat. (1) You can force the library user to
create
> a struct with conformance to `SomeProtocol`. (2) This approach will
accept
> any struct which conforms to that protocol.
>
> As I said in the protocol comment above protocols can only be constrained
> to classes at the moment, and this might change in the future. If we also
> had some sort of things for generics so the function from above might
have
> looked like this:
>
> func foo<T: struct where T: SomeProtocol>(value: T) {}
>
> But it seems that such a thing won’t ever happen to Swift.
>
> Basically `struct<>`, `class<>` and `enum<>` will just enable this for
us.
> `all<>` would accept any type at its first element.
>
> func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>)
> { /* T could be a reference type or value type */ }
>
> That been said, `all<>` could replace `protocol<>` where it is composed
> from protocols. `all<>` can only be used as a generic constraints if the
> first element is a protocol or a reference type.
>
> @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?
>
>
> No. These say nothing about semantics. PureValue is all about the
> semantics of a type and has nothing to do with what mechanism is used to
> implement the type.
>
>
> struct A<T> {
>
> var value: struct<T> // if we drop the strict rule of at least one
> protocols
> }
>
> How does it sound to you?
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 13. Mai 2016 bei 20:34:59, Vladimir.S (svabox@gmail.com) schrieb:
>
> Hmm..
>
> What about such synthetic scenario:
>
> at the moment of writing our code we have:
>
> public protocol MyProtocol {
> func foo()
> }
>
> public struct StructA:MyProtocol {
> func foo()
> }
>
> public struct StructB:MyProtocol {
> func foo()
> }
>
> and have
>
> public protocol ExtraProtocol1 {
> func bar()
> }
>
> public protocol ExtraProtocol2 {
> func blort()
> }
>
> then we actually can have such code:
>
> func f(p: MyProtocol) {
> if let a = p as? struct<StructA, ExtraProtocol1> {
> a.foo()
> a.bar()
> }
> else
> if let b = p as? struct<StructB, ExtraProtocol2> {
> b.foo()
> b.blort()
> }
> }
>
>
>
>
> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
> >> 'struct<>' does seem redundant unless it becomes subtypeable. If
> >> you want a struct which conforms to several protocols, protocol<>
> >> already covers this.
> >>
> >> I think this is not correct. Lets check this example:
> >>
> >> func foo(value: SomeProtocol) {
> >>
> >> if let a = value as? struct<StructA, SomeProtocol> { /* do
> >> something with a */ }
> >>
> >> else if let b = value as? struct<StructB, SomeProtocol> { /* do
> >> something with b */ }
> >>
> >> }
> >>
> >> In this scenario you’ll be able to access properties and functions
> >> from `StructA` or `StructB` which might not be covered by
> >> `SomeProtocol`. Everything is merged nicely into one instance. But
> >> you are right it depends on the use-case.
> >>
> >>
> >> There is no need to include the protocol here. Just do this:
> >>
> >> if let a = value as? StructA { use a }
> >>
> > Whoops, I forgot that this will do the trick. I apologize for any
> confusion
> > here, you are totally right.
> >
> > That been said, do we really need `type<>` aka. `all<>` for value
types?
> I
> > need to rethink this part of the proposal. Is there any use-case where
we
>
> > would need this (any scenario for the future Swift version also
counts)?
>
> >
> > If we had `all<>` in Swift already for extendable reference types and
one
>
> > day structs would become subtypeable, this wouldn’t be a huge problem
to
>
> > upgrade `all<>` for structs I guess.
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> >
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/350b0db2/attachment-0001.html
>

------------------------------

Message: 45
Date: Sat, 14 May 2016 01:05:32 -0400
From: Jon Shier <jon@jonshier.com>
To: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Review] SE-0081: Move where clause to
        end of declaration
Message-ID: <DC2A000A-6322-43A5-BD6D-2C405C745C89@jonshier.com>
Content-Type: text/plain; charset="utf-8"

> * What is your evaluation of the proposal?

-1

No one has been able to explain how this change improves readability, it
just seems like it’s supposed to be self evident. I would argue that it
makes the generic definitions less readable by separating declarations and
their relevant where clauses. At best this change just moves the already
unreadable mass of text elsewhere, where it’s still unreadable.
Furthermore, it trades this supposed readability of generic parameters for
decreased readability of the actual function signature, since that
signature’s now buried between the generic definitions and the where
clauses. This is especially bad when declaring a single generic type that
can easily fit on a single line, such as:

func something<T: Decodable where T == T.DecodedType>(with something: T)
-> String

turns into this, which is less readable to me, as it hides important
information between the generic information:

func something<T: Decodable>(with something: T) -> String where T ==
T.DecodedType

Also, this proposal doesn’t explain how the definitions for generic types
would change. Using the proposed grammar would be even worse on types. From:

final class NetworkOperation<T: Decodable where T == T.DecodedType>:
Operation,… {

to:

final class NetworkOperation<T: Decodable>: Operation,… where T ==
T.DecodedType {

The additional conformances types can have make this an especially bad use
case for this proposal.

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

It can be a problem, but I don’t see how this proposal fixes it.
Appropriate code styling, whether manual or provided by an IDE, could
provide much better readability than this proposal ever could.

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

Changes proposed for “readability” need to be closely scrutinized, as one
programmer’s readable and another’s Perl. I don’t think this proposal meets
the high standard this list has tried to set for things to the language.

> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

Java and C++’s generics, which are rather different. And despite what they
may have intended, I don’t think generics in either language are used as
much as in Swift.

> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Read the proposal, the thread thus far, and considered my response.

Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/a80f432d/attachment-0001.html
>

------------------------------

Message: 46
Date: Sat, 14 May 2016 01:19:49 -0400
From: Jon Shier <jon@jonshier.com>
To: swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] Consistent bridging for
        NSErrors at the language boundary
Message-ID: <C1FE5542-1469-4ECB-B422-D4C7F013CA58@jonshier.com>
Content-Type: text/plain; charset="utf-8"

Charles:
        I appreciate the attempt to minimize a current pain point and I
agree on most of your analysis of the current NSError bridging but I think
your proposal is fundamentally flawed. By forcing the core error type to
have properties from NSError, you’re essentially finalizing what all error
types in Swift should look like. Error domains, codes, and info
dictionaries are not Swift, and forcing every error produced in Swift to
have those properties is a regression from the freedom ErrorType has given
us. No native Swift error type I’ve seen so far has chosen to replicate
those properties, and for good reason: they are a relic of C which have no
place in Swift. There are far better error designs out there. If you want
to propose a strong type of error for Swift, go ahead, but it should be
thoroughly inspired by Swift, not driven by a desire to ease bridging to
NSError.

Jon Shier

> On May 5, 2016, at 3:06 PM, Charles Srstka via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I formerly posted a less-fleshed-out version of this in the “Reducing
bridging magic” thread, but I thought this might warrant its own pitch.
What do you all think?
>
> MOTIVATION:
>
> Over the past couple of years, Swift has made great strides toward
seamless interoperability with existing Objective-C APIs, and with SE-0005,
SE-0033, SE-0057, SE-0062, SE-0064, and SE-0070, seems poised to become
even better in that regard. However, there still exists one major pain
point when going back and forth between Swift and Objective-C, and that
lies in the area of error reporting. Passing errors between Objective-C and
Swift APIs is currently quite awkward, for several reasons:
>
> - The Swift-approved mechanism for reporting errors is a protocol named
ErrorType (ErrorProtocol in the latest sources). However, Objective-C
represent errors using a class named NSError. In addition to being a
reference type, which feels quite unnatural for an error object by Swift’s
conventions, NSError follows a completely paradigm from what most
ErrorProtocol objects use to store errors, using a string-based domain and
and integer code, along with a userInfo dictionary to store information to
be presented to the user. While the domain and code are available as
methods on ErrorProtocol, they are prefixed with underscores, and there is
no direct equivalent to userInfo.
>
> - Unlike other Objective-C classes like NSString and NSArray which are
consistently bridged to value types when presenting Objective-C interfaces
to Swift, the handling of NSError objects is inconsistent. Objective-C APIs
which return an error by reference using an autoreleasing NSError **
pointer are converted to use the Swift try/catch mechanism, presenting the
returned error as an ErrorProtocol (which is actually an NSError).
Similarly, Swift APIs using try/catch are presented to Objective-C as
autoreleasing NSError ** pointers, and the ErrorProtocol-conforming error
is converted to an NSError when it is called by Objective-C. However, when
passing around error objects in any way other than these, the errors are
not bridged. An Objective-C API that takes an NSError, such as NSApp’s
-presentError: method, still leaves NSError as the type in the interface
presented to Swift, as do the many asynchronous APIs in Cocoa that return
an NSError as one of the arguments to a completion handler. Swift APIs that
accept ErrorProtocols, on the other hand, are not presented to Objective-C
at all, necessitating any such APIs also be declared to take NSErrors.
>
> - To convert ErrorProtocols to NSErrors, Swift provides a bridging
mechanism, invoked via “as NSError”, which wraps the error in a private
NSError subclass class called _SwiftNativeNSError. This subclass can be
cast back to the original error type, thus returning the original wrapped
error. When a Swift API that is marked “throws” is called from Objective-C
and then throws an error, the same bridging mechanism is invoked. However,
this bridging is not very useful, since Cocoa tends to use NSError’s
userInfo dictionary to present error information to the user, and
ErrorProtocol contains no equivalent to the userInfo dictionary. The result
of this is that when a Swift API throws an error, and this error is passed
to Cocoa, the user tends to get a generic error message instead of
something actually useful.
>
> - The above problem means that a Swift developer must be very careful
never to use “as NSError”, and to be sure to construct an NSError when
throwing an error in an API that may be called from Objective-C, rather
than simply throwing the error directly, or else the error will not be
properly presented. If the developer makes a mistake here, it will not be
known until runtime. I have personally wasted quite a bit of time trying to
hunt down points in a complicated program where an error was accidentally
converted to NSError via the bridge rather than explicitly.
>
> - The same problem also puts the Swift developer between a rock and a
hard place, if they have other code that wants to check these errors. In a
pure-Swift program, checking against a particular error can often be done
simply via an equality check. If the error has been converted to NSError
via the bridge, this also works, since the bridge will return the original
Swift error when casted. However, if the API that threw the error has been
conscientious about constructing an NSError to avoid the userInfo issue,
the NSError will not be easily castable back to the original Swift error
type. Instead, the developer will have to compare the NSError’s error
domain and code. The code itself will have to have been assigned by the
throwing API. As the domain is stringly-typed and the code will often be
extraneous to the actual error definition, this is all very
runtime-dependent and can easily become incorrect or out of sync, which
will break the program’s error reporting.
>
> - The UI for creating NSError objects is extremely verbose, and
eminently un-Swift-like, usually requiring two lines of code: one to
construct a dictionary, with an extremely verbose
key—NSLocalizedFailureReasonErrorKey—to indicate the actual error message
text to the user, and one to construct the NSError object. The latter is
itself quite verbose, requiring the developer to enter values for a domain
and code which she typically does not care about, since ErrorProtocol
provides decent enough default implementations for those values in most
cases.
>
> - Due to bugs in the bridging mechanism, it is possible for a
_SwiftNativeNSError to get run a second time through the bridge, which
removes the userInfo dictionary altogether, once again result in incorrect
error reporting.
>
> - The need for the “as NSError” bridging mechanism makes it more
difficult to implement otherwise positive changes such as Joe Groff’s
proposal to simplify the “as?” keyword (
https://github.com/apple/swift-evolution/pull/289 <
https://github.com/apple/swift-evolution/pull/289>).
>
> - Finally, the fact that Swift code that deals with errors must always
be filled with either “as NSError” statements or explicit NSError
initializations sprinkled through results in code that is quite a bit
uglier than it needs to be.
>
> PROPOSED APPROACH:
>
> I propose consistently bridging NSError to a value type whenever it is
exposed to Swift code via an API signature, and doing the equivalent in the
opposite direction, similarly to how NSStrings and Strings are bridged to
and from each other in API signatures.
>
> The benefits of this approach are many:
>
> 1. This is very similar to the bridging that already exists for
String<->NSString, Array<->NSArray, when crossing the language boundary, so
this improves the consistency of the language.
>
> 2. Special-case type checks would be mostly restricted to the special
magic that the compiler inserts when crossing the boundary, thus reducing
the potential for bugs.
>
> 3. NSError is no longer required to conform to ErrorProtocol, reducing
the type checking that has to go on during the bridging process, also
reducing the potential for bugs.
>
> 4. Since the is, as, as?, and as! operators would no longer be needed to
bridge NSErrors to native errors and back, improvements to that mechanism
such as (https://github.com/apple/swift-evolution/pull/289 <
https://github.com/apple/swift-evolution/pull/289>) become viable, and
the casting operators can be made to no longer act in ways that are often
surprising and confusing.
>
> 5. The programmer never has to deal with NSError objects in Swift code
again.
>
> DETAILED DESIGN:
>
> 1. Extend ErrorProtocol such that it has public, non-underscored methods
for the domain, code, and userInfo. The first two of these retain their
existing default implementations, whereas the last of these will have a
default implementation that just returns an empty dictionary. The user can
override any of these to provide more information as needed.
>
> 2. NSError’s conformance to ErrorProtocol is removed, since Swift code
will generally no longer need to work directly with NSErrors.
>
> 3. A new private error value type is introduced that conforms to
ErrorProtocol. Since this type will be private, its specific name is up to
the implementers, but for the purpose of this example we will assume that
it is named _ObjCErrorType. This type wraps an NSError, and forwards its
domain, code, and userInfo properties to it.
>
> 4. The existing _SwiftNativeNSError class remains, and continues to work
as it does currently, although it is extended to forward the userInfo
property to the wrapped Swift error. Thus, this class now wraps a native
Swift error and forwards the domain, code, and userInfo properties to it.
>
> 5. Objective-C APIs that return an NSError object present it as
ErrorProtocol in the signature. When called by Swift, the type of the
NSError is checked. If the type is _SwiftNativeNSError, the original Swift
error is unwrapped and returned. Otherwise, the NSError is wrapped in an
instance of _ObjCErrorType and returned as an ErrorProtocol.
>
> 6. Objective-C APIs that take NSError objects now show ErrorProtocol in
their signatures as well. If an _ObjCErrorType is passed to one of these
APIs, its wrapped NSError is unwrapped and passed to the API. Otherwise,
the error is wrapped in a _SwiftNativeNSError and passed through to the API.
>
> 7. Swift errors would still be convertible to NSError, if the developer
needed to do so manually. This could be done either via the current “as
NSError” bridge, or via initializers and/or accessors on NSError.
>
> IMPACT ON EXISTING CODE:
>
> Required changes to existing code will mostly involve removing “as
NSError” statements. Workarounds to the problem being addressed by this
change will probably also want to be removed, as they will no longer be
needed.
>
> ALTERNATIVES CONSIDERED:
>
> Do nothing, and let the terrorists win.
>
> Charles
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/480f784a/attachment-0001.html
>

------------------------------

Message: 47
Date: Sat, 14 May 2016 15:20:05 +1000
From: Patrick Smith <pgwsmith@gmail.com>
To: Kevin Ballard <kevin@sb.org>
Cc: swift-evolution@swift.org
Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,
        prefix(while:), drop(while:), and iterate to the stdlib
Message-ID: <9264E8FF-0A0E-4CC9-BF8E-51E0B67B5752@gmail.com>
Content-Type: text/plain; charset="utf-8"

Would there be any issue with the return type being AnySequence? It’s used
in other areas:

LazySequence & FlattenSequence’s
dropFirst(n: Int) -> AnySequence<Generator.Element>
dropLast(n: Int) -> AnySequence<Generator.Element>

No need to introduce another type, and it’s straight forward to implement
with AnySequence.

> On 14 May 2016, at 5:07 AM, Kevin Ballard via swift-evolution < > swift-evolution@swift.org> wrote:
>
> On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
>> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>> The proposal has been updated as per feedback from the core team (
https://github.com/apple/swift-evolution/pull/275 <
https://github.com/apple/swift-evolution/pull/275>). This includes
removing some last vestiges of Swift 2 naming as well as replacing
`iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.
>>>
>>> The proposal says this:
>>>
>>> public func unfold<T, State>(_ initialState: State, applying: State
-> (T, State)?) -> UnfoldSequence<T>
>>> public func unfold<T>(_ initialElement: T, apply: T -> T) ->
UnfoldSequence<T>
>>>
>>> However, the comment implies that the second one should instead be
this:
>>>
>>> public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
UnfoldSequence<T>
>>>
>>> I'm not sure I like having these be overloaded on only the return type
of the closure. Maybe we could do something like this?
>>>
>>> public func unfold<T, State>(fromState initialState: State, applying:
State -> (T, State)?) -> UnfoldSequence<T>
>>> public func unfold<T>(fromFirst initialElement: T, apply: T -> T) ->
UnfoldSequence<T>
>>>
>>> That way you're calling either `unfold(fromState:applying:)` or
`unfold(fromFirst:applying:)`. (Some further bikeshedding might be needed
here—it's late and I'm tired.)
>>
>>
>> I really don't want to see this discussion die as I have a vested
interest in getting this functionality into
>> Swift 3. So let me suggest that
>>
>> `sequence(_:, next:) -> AdHocSequence`
>>
>> might be a Swift acceptable solution. We're not going to see
fold/unfold pair happen. It's a given that
>> `reduce` is a fixed point in Swift space and `sequence` well describes
what this should be doing.
>>
>> So is it possible to push forward with `sequence`, whose only negative
seems to be that it's not as well
>> loved as `unfold`?
>
> I do like `sequence`, though I'm not sold on the name AdHocSequence
(just from that name it's hard to figure out what it does). An alternative
is `expand`, which is nice because it pairs with `reduce`, but it's less
obvious that it produces a sequence and the name isn't as good with the
stateful version.
>
> As for return type name, we could go ahead and use UnfoldSequence<T>
anyway even though the function isn't named `unfold`, because this name
will make sense to people who do know what unfold is, and I'm not convinced
we can have a meaningful name for people who don't (since SequenceSequence
is too silly).
>
> So given that, I'll suggest the following:
>
> func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T>
> func sequence<T, State>(state: State, next: (inout State) -> T?) ->
UnfoldSequence<T>
>
> I'm suggesting `sequence(initial:next:)` instead of the
previously-suggested `sequence(from:applying:)` because the term "from"
could equally well mean the first element or the state, whereas "initial"
should make it more obvious that this value is the first element of the
resulting sequence. And I'm using "next" as suggested by Erica because the
function does return the next element, and it's similar to the
IteratorProtocol method. I've also chosen to change the stateful version to
use an inout parameter, as previously suggested, because it's equivalent to
the State -> (T, State)? in functionality but is less likely to produce
unwanted COW copies.
>
> -Kevin Ballard
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/760d1ed4/attachment.html
>

------------------------------

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

End of swift-evolution Digest, Vol 6, Issue 45
**********************************************