Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs
through March 7, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md
Reviews are an important part of the Swift evoluti
Composing a base class and protocol requirements opens up the possibility of
using the base class to constrain away a protocol's associated types, e.g.:
protocol P { associatedtype T; func foo(_: T) }
class C: P { func foo(_: T) {}
It'd be worth calling out explicitly whether this proposal allow
>
> What is your evaluation of the proposal?
+1, this is a fantastic proposal! I
The proposal does not specifically call out whether a class may inherit from a
subclass of a superclass constraint when a typealias is used in the inheritance
list. I believe the following should be valid, but it
What is your evaluation of the proposal?
It seems to be a very straightforward and natural extension of existing syntax
to bring Swift closer to the functionality of Objective-C and other languages.
My only concern is that using `AnyObject` at first glance seems less
descriptive than ‘class’ w
Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement of
'P' to make it interesting ('C & Q').
Jordan
> On Feb 28, 2017, at 13:20, Joe Groff via swift-evolution
> wrote:
>
> Composing a base class and protocol requirements opens up the possibility of
> using the base class to
> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution
> wrote:
>
>>
>> What is your evaluation of the proposal?
> +1, this is a fantastic proposal! I
>
> The proposal does not specifically call out whether a class may inherit from
> a subclass of a superclass constraint when a typ
> On 28 Feb 2017, at 22:52, Christopher Kornher via swift-evolution
> wrote:
>
> What is your evaluation of the proposal?
> It seems to be a very straightforward and natural extension of existing
> syntax to bring Swift closer to the functionality of Objective-C and other
> languages.
>
> M
> On Feb 28, 2017, at 4:14 PM, David Hart wrote:
>
>
>> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>> What is your evaluation of the proposal?
>> +1, this is a fantastic proposal! I
>>
>> The proposal does not specific
> On Feb 28, 2017, at 2:28 PM, Matthew Johnson via swift-evolution
> wrote:
>
>>
>> On Feb 28, 2017, at 4:14 PM, David Hart wrote:
>>
>>
>>> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution
>>> wrote:
>>>
• What is your evaluation of the proposal?
>>> +1, this
> On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution
> wrote:
>
> Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement
> of 'P' to make it interesting ('C & Q').
>
> Jordan
>
Or conformance to P needs to be conditional.
That is my only issue with this proposal: why
> On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution
> wrote:
>
> Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement
> of 'P' to make it interesting ('C & Q’).
Could generic specialisation be disallowed in constraints? I need to think
about this.
> Jordan
>
>> On
1) What is your evaluation of the proposal?
This is a critical must have feature in Swift. I’ve been waiting for it since
Swift 1.2.
2) Is the problem being addressed significant enough to warrant a change to
Swift?
Absolutely.
3) Does this proposal fit well with the feel and direction of Swi
> On Feb 28, 2017, at 10:39 PM, David Hart wrote:
>
>>
>> On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement
>> of 'P' to make it interesting ('C & Q’).
>
> Could
Using ": class" always felt wrong for me — but only because of the convention
that type names should start uppercase:
What is wrong with "Class" instead of "AnyObject"?
Object is a very broad term, and it isn't that uncommon to use it for all kinds
of entities (not only reference types).
And what
And what if we ever decide that restricting protocols to structs or enums
should be allowed as well?
AnyValue (_might_ happen with value sub typing)?
Or maybe there are secret plans to add new reference types to Swift?
Classes aren’t the only reference types in Swift, functions are also reference
What is your evaluation of the proposal?
+1
Is the problem being addressed significant enough to warrant a change to
Swift?
Yes
Does this proposal fit well with the feel and direction of Swift?
Yes
How much effort did you put into your review? A glance, a quick reading, or
an in-de
16 matches
Mail list logo
