Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution 
>  wrote:
> 
> I wouldn't mind driving the discussion and proposal, because I'd really like 
> to see a more complete generics system. Before I start, can David or Doug, or 
> someone else with a high-level view of the generics system tell me if this is 
> where to start or if there is another feature in the Complete Generics 
> manifesto which is more urgent first?

I think this is a fine feature to focus on. It’s useful, fits well in the 
system, and it’s scope is small enough that it’s achievable.

- Doug

> 
> David
> 
> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution 
> > wrote:
> 
>> I'm interested, but I'm by no means claiming I'll have enough time to drive 
>> any of the discussion/proposal/implementation. :-(
>> 
>> Jacob
>> 
>> On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Tue Apr 12 2016, Douglas Gregor > > wrote:
>> 
>> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> > > wrote:
>> >
>> > Doug wrote this in the Completing Generics manifesto, under "Minor
>> > extensions":
>> >
>> > *Arbitrary requirements in protocols
>> >
>> > Currently, a new protocol can inherit from other protocols, 
>> > introduce
>> > new associated types, and add new conformance constraints to 
>> > associated
>> > types (by redeclaring an associated type from an inherited 
>> > protocol).
>> > However, one cannot express more general constraints. Building on 
>> > the
>> > example from “Recursive protocol constraints”, we really want the
>> > element type of a Sequence’s SubSequence to be the same as the 
>> > element
>> > type of the Sequence, e.g.,
>> >
>> > protocol Sequence {
>> > associatedtype Iterator : IteratorProtocol
>> > …
>> > associatedtype SubSequence : Sequence where 
>> > SubSequence.Iterator.Element
>> > == Iterator.Element
>> > }
>> >
>> > +1.
>> >
>> > To make it into Swift 3, would this feature require a proposal of its 
>> > own?
>> >
>> > Yes. Also, be wary that the syntax above potentially conflicts with the 
>> > syntax
>> > discussed as "moving the where clauses”:
>> >
>> > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 
>> > 
>> >
>> > How feasible would it be to implement on top of the current system?
>> >
>> > Definitely! The archetype builder would need to learn to check these extra 
>> > where
>> > clauses, and one would need to be sure that the constraint solver is 
>> > picking
>> > them up as well.
>> 
>> By the way, having this would enable us to massively simplify the
>> standard library, and potentially lots of user-written generic code,
>> too.  So I'm very excited that someone's interested!
>> 
>> --
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 12, 2016, at 11:19 PM, David Hart  wrote:
> 
> Hi Doug,
> 
> I've read the discussion about moving the where clause to the right of 
> declarations (which I full-heartedly approve) but I don't see how it would 
> have any impact on the syntax of associated types requirements.

I think “arbitrary requirements in protocols” doesn’t necessarily require them 
to be attached to an associated type. For example, Collection might require 
that the SubSequence type itself be a Collection:

protocol Collection : Sequence {
  associatedtype SubSequence : Collection
} 

Why did we have to declare the SubSequence associated type again (since it’s 
already down in SubSequence) just to make it conform to Collection. In fact, 
why are we even allowed to declare a redundant associated type, which we know 
is defined in Sequence and will have to be the same? Seems to me that we just 
want a where clause to add the constraint, e.g.,

protocol Collection : Sequence {
  where SubSequence : Collection
} 

which of course would conflict with moving where clauses later, e.g.,

protocol Collection : Sequence {
  func foo() // is the following where clause part of foo() or part of 
Collection?
  where SubSequence : Collection
} 


- Doug


> 
> David
> 
> On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>>> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> Doug wrote this in the Completing Generics manifesto, under "Minor 
>>> extensions":
>>> 
>>> *Arbitrary requirements in protocols
>>>  
>>> Currently, a new protocol can inherit from other protocols, introduce new 
>>> associated types, and add new conformance constraints to associated types 
>>> (by redeclaring an associated type from an inherited protocol). However, 
>>> one cannot express more general constraints. Building on the example from 
>>> “Recursive protocol constraints”, we really want the element type of a 
>>> Sequence’s SubSequence to be the same as the element type of the Sequence, 
>>> e.g.,
>>>  
>>> protocol Sequence {
>>> associatedtype Iterator : IteratorProtocol
>>> …
>>> associatedtype SubSequence : Sequence where 
>>> SubSequence.Iterator.Element == Iterator.Element
>>> }
>>> 
>>> 
>>> +1.
>>> 
>>> To make it into Swift 3, would this feature require a proposal of its own?
>> 
>> Yes. Also, be wary that the syntax above potentially conflicts with the 
>> syntax discussed as "moving the where clauses”:
>> 
>>  
>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 
>> 
>> 
>> 
>>> How feasible would it be to implement on top of the current system?
>> 
>> Definitely! The archetype builder would need to learn to check these extra 
>> where clauses, and one would need to be sure that the constraint solver is 
>> picking them up as well.
>> 
>>  - Doug
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[David Hart via swift-evolution]

I wouldn't mind driving the discussion and proposal, because I'd really like to 
see a more complete generics system. Before I start, can David or Doug, or 
someone else with a high-level view of the generics system tell me if this is 
where to start or if there is another feature in the Complete Generics 
manifesto which is more urgent first?

David

> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> I'm interested, but I'm by no means claiming I'll have enough time to drive 
> any of the discussion/proposal/implementation. :-(
> 
> Jacob
> 
>> On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Tue Apr 12 2016, Douglas Gregor  wrote:
>> 
>> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> >  wrote:
>> >
>> > Doug wrote this in the Completing Generics manifesto, under "Minor
>> > extensions":
>> >
>> > *Arbitrary requirements in protocols
>> >
>> > Currently, a new protocol can inherit from other protocols, 
>> > introduce
>> > new associated types, and add new conformance constraints to 
>> > associated
>> > types (by redeclaring an associated type from an inherited 
>> > protocol).
>> > However, one cannot express more general constraints. Building on 
>> > the
>> > example from “Recursive protocol constraints”, we really want the
>> > element type of a Sequence’s SubSequence to be the same as the 
>> > element
>> > type of the Sequence, e.g.,
>> >
>> > protocol Sequence {
>> > associatedtype Iterator : IteratorProtocol
>> > …
>> > associatedtype SubSequence : Sequence where 
>> > SubSequence.Iterator.Element
>> > == Iterator.Element
>> > }
>> >
>> > +1.
>> >
>> > To make it into Swift 3, would this feature require a proposal of its 
>> > own?
>> >
>> > Yes. Also, be wary that the syntax above potentially conflicts with the 
>> > syntax
>> > discussed as "moving the where clauses”:
>> >
>> > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
>> >
>> > How feasible would it be to implement on top of the current system?
>> >
>> > Definitely! The archetype builder would need to learn to check these extra 
>> > where
>> > clauses, and one would need to be sure that the constraint solver is 
>> > picking
>> > them up as well.
>> 
>> By the way, having this would enable us to massively simplify the
>> standard library, and potentially lots of user-written generic code,
>> too.  So I'm very excited that someone's interested!
>> 
>> --
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[David Hart via swift-evolution]

Hi Doug,

I've read the discussion about moving the where clause to the right of 
declarations (which I full-heartedly approve) but I don't see how it would have 
any impact on the syntax of associated types requirements.

David

> On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>>>  wrote:
>>> 
>>> Doug wrote this in the Completing Generics manifesto, under "Minor 
>>> extensions":
>>> 
>> 
>>> *Arbitrary requirements in protocols
>>>  
>>> Currently, a new protocol can inherit from other protocols, introduce new 
>>> associated types, and add new conformance constraints to associated types 
>>> (by redeclaring an associated type from an inherited protocol). However, 
>>> one cannot express more general constraints. Building on the example from 
>>> “Recursive protocol constraints”, we really want the element type of a 
>>> Sequence’s SubSequence to be the same as the element type of the Sequence, 
>>> e.g.,
>>>  
>>> protocol Sequence {
>>> associatedtype Iterator : IteratorProtocol
>>> …
>>> associatedtype SubSequence : Sequence where 
>>> SubSequence.Iterator.Element == Iterator.Element
>>> }
>> 
>> 
>> +1.
>> 
>> To make it into Swift 3, would this feature require a proposal of its own?
> 
> Yes. Also, be wary that the syntax above potentially conflicts with the 
> syntax discussed as "moving the where clauses”:
> 
>   
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
> 
> 
>> How feasible would it be to implement on top of the current system?
> 
> Definitely! The archetype builder would need to learn to check these extra 
> where clauses, and one would need to be sure that the constraint solver is 
> picking them up as well.
> 
>   - Doug
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Jacob Bandes-Storch via swift-evolution]

I'm interested, but I'm by no means claiming I'll have enough time to drive
any of the discussion/proposal/implementation. :-(

Jacob

On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Apr 12 2016, Douglas Gregor  wrote:
>
> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
> >  wrote:
> >
> > Doug wrote this in the Completing Generics manifesto, under "Minor
> > extensions":
> >
> > *Arbitrary requirements in protocols
> >
> > Currently, a new protocol can inherit from other protocols,
> introduce
> > new associated types, and add new conformance constraints to
> associated
> > types (by redeclaring an associated type from an inherited
> protocol).
> > However, one cannot express more general constraints. Building
> on the
> > example from “Recursive protocol constraints”, we really want the
> > element type of a Sequence’s SubSequence to be the same as the
> element
> > type of the Sequence, e.g.,
> >
> > protocol Sequence {
> > associatedtype Iterator : IteratorProtocol
> > …
> > associatedtype SubSequence : Sequence where
> SubSequence.Iterator.Element
> > == Iterator.Element
> > }
> >
> > +1.
> >
> > To make it into Swift 3, would this feature require a proposal of
> its own?
> >
> > Yes. Also, be wary that the syntax above potentially conflicts with the
> syntax
> > discussed as "moving the where clauses”:
> >
> >
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
> >
> > How feasible would it be to implement on top of the current system?
> >
> > Definitely! The archetype builder would need to learn to check these
> extra where
> > clauses, and one would need to be sure that the constraint solver is
> picking
> > them up as well.
>
> By the way, having this would enable us to massively simplify the
> standard library, and potentially lots of user-written generic code,
> too.  So I'm very excited that someone's interested!
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Dave Abrahams via swift-evolution]

on Tue Apr 12 2016, Douglas Gregor  wrote:

> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>  wrote:
>
> Doug wrote this in the Completing Generics manifesto, under "Minor
> extensions":
>
> *Arbitrary requirements in protocols
>
> Currently, a new protocol can inherit from other protocols, introduce
> new associated types, and add new conformance constraints to 
> associated
> types (by redeclaring an associated type from an inherited protocol).
> However, one cannot express more general constraints. Building on the
> example from “Recursive protocol constraints”, we really want the
> element type of a Sequence’s SubSequence to be the same as the element
> type of the Sequence, e.g.,
>
> protocol Sequence {
> associatedtype Iterator : IteratorProtocol
> …
> associatedtype SubSequence : Sequence where 
> SubSequence.Iterator.Element
> == Iterator.Element
> }
>
> +1.
>
> To make it into Swift 3, would this feature require a proposal of its 
> own? 
>
> Yes. Also, be wary that the syntax above potentially conflicts with the syntax
> discussed as "moving the where clauses”:
>
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
>
> How feasible would it be to implement on top of the current system?
>
> Definitely! The archetype builder would need to learn to check these extra 
> where
> clauses, and one would need to be sure that the constraint solver is picking
> them up as well.

By the way, having this would enable us to massively simplify the
standard library, and potentially lots of user-written generic code,
too.  So I'm very excited that someone's interested!

-- 
Dave

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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Doug wrote this in the Completing Generics manifesto, under "Minor 
> extensions":
> 
> *Arbitrary requirements in protocols
>  
> Currently, a new protocol can inherit from other protocols, introduce new 
> associated types, and add new conformance constraints to associated types (by 
> redeclaring an associated type from an inherited protocol). However, one 
> cannot express more general constraints. Building on the example from 
> “Recursive protocol constraints”, we really want the element type of a 
> Sequence’s SubSequence to be the same as the element type of the Sequence, 
> e.g.,
>  
> protocol Sequence {
> associatedtype Iterator : IteratorProtocol
> …
> associatedtype SubSequence : Sequence where 
> SubSequence.Iterator.Element == Iterator.Element
> }
> 
> 
> +1.
> 
> To make it into Swift 3, would this feature require a proposal of its own?

Yes. Also, be wary that the syntax above potentially conflicts with the syntax 
discussed as "moving the where clauses”:


http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058


> How feasible would it be to implement on top of the current system?

Definitely! The archetype builder would need to learn to check these extra 
where clauses, and one would need to be sure that the constraint solver is 
picking them up as well.

- Doug


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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Maximilian Hünenberger via swift-evolution]

Hi Jacob,

I really like the idea of constraining associated types. However I think there 
could be a much more general solution to this problem by introducing "Partially 
constrained protocols".

I've already created a (almost finished) proposal for another thread which 
hasn't continued. It attacks the same issue as "Arbitrary requirements in 
protocols": 
https://github.com/Qbyte248/swift-evolution/blob/master/proposals/-Partially%20constrained%20protocols%20and%20generic%20types.md

Unfortunately I have (almost) no time to discuss this in depth or completely 
finish the proposal. So feel free to copy my proposal add yourself as coauthor 
and start a new thread. Or just take it as an inspiration :)

Kind regards
- Maximilian

PS: Looking forward to a new generics model :)

> Am 11.04.2016 um 10:01 schrieb Jacob Bandes-Storch via swift-evolution 
> :
> 
> Doug wrote this in the Completing Generics manifesto, under "Minor 
> extensions":
> 
>> *Arbitrary requirements in protocols
>>  
>> Currently, a new protocol can inherit from other protocols, introduce new 
>> associated types, and add new conformance constraints to associated types 
>> (by redeclaring an associated type from an inherited protocol). However, one 
>> cannot express more general constraints. Building on the example from 
>> “Recursive protocol constraints”, we really want the element type of a 
>> Sequence’s SubSequence to be the same as the element type of the Sequence, 
>> e.g.,
>>  
>> protocol Sequence {
>> associatedtype Iterator : IteratorProtocol
>> …
>> associatedtype SubSequence : Sequence where 
>> SubSequence.Iterator.Element == Iterator.Element
>> }
> 
> 
> +1.
> 
> To make it into Swift 3, would this feature require a proposal of its own? 
> How feasible would it be to implement on top of the current system?
> 
> Jacob
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Dave Abrahams via swift-evolution]

on Mon Apr 11 2016, Jacob Bandes-Storch  wrote:

> On Mon, Apr 11, 2016 at 11:56 AM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Mon Apr 11 2016, Jacob Bandes-Storch  wrote:
>
> > Doug wrote this in the Completing Generics manifesto, under "Minor
> extensions":
> >
> > *Arbitrary requirements in protocols
> >
> > Currently, a new protocol can inherit from other protocols, introduce 
> new
> > associated types, and add new conformance constraints to associated 
> types
> > (by redeclaring an associated type from an inherited protocol). However,
> one
> > cannot express more general constraints. Building on the example from
> > “Recursive protocol constraints”, we really want the element type of a
> > Sequence’s SubSequence to be the same as the element type of the 
> Sequence,
> > e.g.,
> >
> > protocol Sequence {
> > associatedtype Iterator : IteratorProtocol
> > …
> > associatedtype SubSequence : Sequence where SubSequence.Iterator.Element
> ==
> > Iterator.Element
> > }
> >
> > +1.
> >
> > To make it into Swift 3, would this feature require a proposal of its
> > own?
>
> It could be part of another proposal, but it should be in a proposal.
> Whether or not it can still make Swift 3, I am unsure.
>
> > How feasible would it be to implement on top of the current system?
>
> I can't answer that, but if you want to work on this I'd suggest
> starting with the implementation. In this case, the proposal is the
> easy part.
>
> I was mostly wondering if anyone inside the team has already thought about how
> to do this, or perhaps even started working on it. If it's in the pipeline, it
> might affect our discussion about "allValues" for enums (which I'm going to 
> send
> an email about soon).

AFAIK, nobody has started it yet.

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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Jacob Bandes-Storch via swift-evolution]

On Mon, Apr 11, 2016 at 11:56 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon Apr 11 2016, Jacob Bandes-Storch  wrote:
>
> > Doug wrote this in the Completing Generics manifesto, under "Minor
> extensions":
> >
> > *Arbitrary requirements in protocols
> >
> > Currently, a new protocol can inherit from other protocols,
> introduce new
> > associated types, and add new conformance constraints to associated
> types
> > (by redeclaring an associated type from an inherited protocol).
> However, one
> > cannot express more general constraints. Building on the example from
> > “Recursive protocol constraints”, we really want the element type of
> a
> > Sequence’s SubSequence to be the same as the element type of the
> Sequence,
> > e.g.,
> >
> > protocol Sequence {
> > associatedtype Iterator : IteratorProtocol
> > …
> > associatedtype SubSequence : Sequence where
> SubSequence.Iterator.Element ==
> > Iterator.Element
> > }
> >
> > +1.
> >
> > To make it into Swift 3, would this feature require a proposal of its
> > own?
>
> It could be part of another proposal, but it should be in a proposal.
> Whether or not it can still make Swift 3, I am unsure.
>
> > How feasible would it be to implement on top of the current system?
>
> I can't answer that, but if you want to work on this I'd suggest
> starting with the implementation.  In this case, the proposal is the
> easy part.
>

I was mostly wondering if anyone inside the team has already thought about
how to do this, or perhaps even started working on it. If it's in the
pipeline, it might affect our discussion about "allValues" for enums (which
I'm going to send an email about soon).


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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Dave Abrahams via swift-evolution]

on Mon Apr 11 2016, Jacob Bandes-Storch  wrote:

> Doug wrote this in the Completing Generics manifesto, under "Minor 
> extensions":
>
> *Arbitrary requirements in protocols
>
> Currently, a new protocol can inherit from other protocols, introduce new
> associated types, and add new conformance constraints to associated types
> (by redeclaring an associated type from an inherited protocol). However, 
> one
> cannot express more general constraints. Building on the example from
> “Recursive protocol constraints”, we really want the element type of a
> Sequence’s SubSequence to be the same as the element type of the Sequence,
> e.g.,
>
> protocol Sequence {
> associatedtype Iterator : IteratorProtocol
> …
> associatedtype SubSequence : Sequence where SubSequence.Iterator.Element 
> ==
> Iterator.Element
> }
>
> +1.
>
> To make it into Swift 3, would this feature require a proposal of its
> own? 

It could be part of another proposal, but it should be in a proposal.
Whether or not it can still make Swift 3, I am unsure.

> How feasible would it be to implement on top of the current system?

I can't answer that, but if you want to work on this I'd suggest
starting with the implementation.  In this case, the proposal is the
easy part.

-- 
Dave

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