> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution
> wrote:
>
>> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution
>> > wrote:
>>
>> I definitely agree that it's a feature that
I should add, the reason final is inapt in this situation is at least
twofold.
The first is, of course, that this makes it impossible to guarantee source
compatibility and offer additional functionality in a protocol extension,
since any such addition would break unknowable amounts of existing
Well, the revised integer protocols that were just approved do just that:
some functions are defaults and others cannot be overridden. Smart shifts,
for example, are deliberately not customization points. This is also the
case for Equatable: you get to define ==, but != is not a protocol
@Brent,
What aspects of the current proposal do you have reservations about?
-- Howard.
On 3 May 2017 at 18:09, Brent Royal-Gordon wrote:
> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I definitely agree that
> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution
> wrote:
>
> I definitely agree that it's a feature that _can_ be used unwisely, but the
> fact remains that it _is_ used pervasively in the standard library, and
> deliberately
I'm not so sure that's
You raise three points:
1. The harm is the inconsistent behaviour of extensions for both structs and
classes, as outlined in the first section of the proposal. This is confusing
for beginners and difficult to debug in large code bases, particularly those
involving third party libraries were
I'm sorry, it's been a while. What is the harm that you are trying to cure,
and how does this design accomplish that task?
What you call "unexpected" is intentional. Many protocols, including the
revised integer protocols that were just approved, distinguish between
protocol requirements for
I haven't replied to these messages for a while since it has taken some
time to formulate a proposal that incorporates the feedback give - thanks
for the feedback.
The new proposal allows retroactively added protocols to be exported and
ad-hoc code reuse, the two areas of concern.
Comments?
+1
Extensions are a great feature and I’m really glad that Swift has them.
Conflicts should be handled by improving import and disambiguation features
like Xiaodi says which is useful for other cases as well.
-Thorsten
> Am 18.04.2017 um 03:47 schrieb Xiaodi Wu via swift-evolution
>
Neat. Seems like that'd be a bug.
On Wed, Apr 19, 2017 at 9:40 PM, Howard Lovatt
wrote:
> As it stands at the moment splitting to multiple files doesn't work. EG:
>
> ModuleA
>
> A.swift
>
> public protocol P {
>
> func m() -> String
>
> }
>
> extension Int: P {
>
>
As it stands at the moment splitting to multiple files doesn't work. EG:
ModuleA
A.swift
public protocol P {
func m() -> String
}
extension Int: P {
public func m() -> String {
return "AP.m"
}
}
ModuleB
B.swift
public protocol P {
func m() -> String
}
extension Int: P {
public func
Simple: you put the user code that needs the more accurate library in one
file and import only the more accurate library there, and you put the user
code that needs the more performant library in a separate file and import
only the more performant library there! Swift's devotion to file-based
Comments in-line below
-- Howard.
On 17 Apr 2017, at 9:01 am, Xiaodi Wu wrote:
This continues to forbid use cases that are critical.
I think "critical" is overstating the importance. Plenty of successful
languages do not have extensions. Extensions have been discussed
This continues to forbid use cases that are critical.
For instance, I am writing a library that vends additional conformances for
Float and Double. Any numerics library would need to do the same.
Your design would eliminate all such libraries, which is a non-starter. I
am not sure what defects
@Brent,
I have updated the proposal to address your concerns, in particular I don't see
that retrospectively adding methods and protocols has been removed it has just
had its ugly corners rounded. See revised proposal below particularly the end
of section "Retrospectively adding protocols and
> On Apr 13, 2017, at 3:10 PM, Howard Lovatt via swift-evolution
> wrote:
>
> I don't see that retroactive conformance needs to be exportable. If it is
> exported then you cannot prevent clashes from two modules, this is a known
> problem in C#. Because of this and
I don't see that retroactive conformance needs to be exportable. If it is
exported then you cannot prevent clashes from two modules, this is a known
problem in C#. Because of this and other problems with C# extensions, this
style of extension were rejected by other language communities (notably
The retroactive conformance needs to be exportable. If one cannot vend a
library that conforms standard library types to new protocols, then that is
a non-starter.
On Thu, Apr 13, 2017 at 06:07 Howard Lovatt wrote:
> @Xiaodi,
>
> You can safely post-hoc add protocols
@Xiaodi,
You can safely post-hoc add protocols and methods provided that they are final,
do not override, and are not exported from the module. See version 2 of the
proposal below.
-- Howard.
# Proposal: Split extension usage up into implementing methods and adding
methods and protocols
Thanks for the explanation Adrian, I also had to Google this :)
Personally I'd love some kind of solution that would prevent this confusion
of why this method does different things when called on the same object in
two different ways, but I don't have any ideas how this could be solved...
It's
I myself pitched that requirement quite a few times on the list. Thank you,
finally I understood why it’s not possible. Now I fully agree that the
requirement of an override should not exist for the base type conforming to the
protocol.
For those who might misunderstand the concept of
On 11.04.2017 1:51, Xiaodi Wu via swift-evolution wrote:
> On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution
> > wrote:
>
> In response to Jordan Rose's comment I suggest the following change:
>
> Proposal:
As far as I'm aware, eliminating retroactive conformances is a non-starter.
On Mon, Apr 10, 2017 at 21:44 Howard Lovatt wrote:
> @Xiaodi,
>
> You make two drugs.
>
> 1. Deliberately making retroactive conformance outside of the file in
> which the type is declared
@Xiaodi,
You make two drugs.
1. Deliberately making retroactive conformance outside of the file in which the
type is declared illegal because of the problems it causes. See all the
questions on Swift Users and watch people learning Swift get caught out.
2. Outside of the file in which the
On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:
> In response to Jordan Rose's comment I suggest the following change:
>
> Proposal: Split extension usage up into implementing methods and adding
> static functions
>
>
> Currently extension
In response to Jordan Rose's comment I suggest the following change:
Proposal: Split extension usage up into implementing methods and adding static
functions
Currently extension methods are confusing because they have different dispatch
rules for the same syntax. EG:
protocol P {
26 matches
Mail list logo