[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Xiaodi Wu]

On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun <erica at ericasadun.com> wrote:

> Can you give me a specific example of where this approach fails for you?
>
> -- E
>


Sure, I'll describe one (renaming some things for clarity and stripping out
the meat of the code, because it's not relevant and because it's not
elegant)--

In one file, I have:

```
class PortedTransfom {
// this class was ported from C++
// it transforms input FP values to output values in a complicated way
// it's a standalone entity and the algorithm is even under patent
// (not owned by me, though it's legal for me to use it for my purposes)
// for this reason, this ported code lives in its own file
}
```

In another file, I have:

```
class MyAsinhTransform {
// this class was written by me
// nothing earth-shattering here
}

class MyLogTransform {
// also written by me
}

class MyLinearTransform {
// also written by me
}
```

Transforming values one-at-a-time isn't fast enough, so in another file, I
have:

```
import Accelerate

protocol AcceleratedTransform {
  func scale(_: [Double]) -> [Double]
  func unscale(_: [Double]) -> [Double]
// other functions here
// some are already implemented in PortedTransform, though
}
extension AcceleratedTransform {
// default implementations for some functions
// but not `scale(_:)` and `unscale(_:)`, obviously
}

extension MyAsinhTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
// and override some default implementations
}

extension MyLogTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
// and override some default implementations
}

extension  MyLinearTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
// and override some default implementations
}

extension PortedTransform : AcceleratedTransform {
// use BLAS to implement scale(_:) and unscale(_:)
}
```

On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I'm not sure that I'm entirely happy with this distinction between already
> compiled types and ones that have not yet been compiled. It's a common
> Swift idiom to implement protocol requirements in extensions, which
> encourages a kind of modularity, if you will. Every so often (and maybe
> this isn't best practice), I incorporate third-party code into a project in
> source form and not as a compiled library (with attribution, and in
> compliance with the license, etc., obviously). Often these are little
> snippets, perhaps useful helper functions or types. The beauty of
> extensions is that I can extend these as necessary without touching the
> original code. The point is, here one would not be able to implement
> certain things in that way if this proposal is adopted. To say that the
> workaround is just editing the original code is deeply unsatisfying,
> because it would be equally valid to say that the same workaround applies
> to stripping out extensions altogether for non-imported types.
>
>
> On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> It is a good idea to explicitly document the behaviour that this
>> requirement for override is a compile time check only and does not mean
>> that already compiled code has to be recompiled to allow a protocol to be
>> retroactively fitted to an already compiled type.
>>
>>
>> On Friday, 29 April 2016, Matthew Johnson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Apr 28, 2016, at 5:49 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>>
>>>
>>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson <matthew at anandabits.com>
>>> wrote:
>>> We can't add the keywords if the structs are defined in a module we
>>> import but don't own.  We are only declaring the conformance
>>> retroactively.  The ability to do this is a crucial aspect of generic
>>> programming.  It isn't yet clear how your proposal handles retroactive
>>> modeling.
>>>
>>>
>>> These are compile-time checks and should not affect compiled code.
>>>
>>>
>>> Does that mean the conformance declaration will be accepted by the
>>> compiler under your proposal?  I would really like to see this called out
>>> explicitly in the proposal.
>>>
>>>
>>> -- E
>>>
>>>
>>
>> --
>> -- Howard.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at 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/20160428/2014e415/attachment.html>