[swift-evolution] [Pitch] `let` in protocols

[Xiaodi Wu]

So your proposed definition of a partial initializer is one that does not
set any protocol requirement?
On Sun, Jun 25, 2017 at 14:54 Robert Bennett <rltbennett at icloud.com> wrote:

> The compiler would only raise an error when a conforming type violated the
> requirement that the partial initializer not set x. The protocol itself
> would never fail to compile.
>
> On Jun 25, 2017, at 3:33 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Jun 25, 2017 at 2:24 PM, Robert Bennett via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> You’re right Xiaodi, I did not entirely think this through. However I
>> think this could still work with another addition to the language: partial
>> initializers. These would be treated as initializers are now (meaning, for
>> instance, no reference to self until initialization is complete) except
>> they would only need to initialize a subset of the instance variables
>> before exiting. An initializer could then satisfy the requirement that all
>> instance variables must be initialized by calling partial initializers.
>>
>> By incorporating partial initializers, it would be possible to guarantee
>> that a `let` variable in a protocol is only set once. This is because an
>> init implemented in a protocol extension could delegate to a partial
>> initializers required by the protocol, and because they are only partial
>> initializers, they need not set the instance variables already set in the
>> initializer; it would be up to a conforming type to ensure this is the
>> caee. A confirming type would define the partial initializer to set
>> everything not already set in the protocol extension’s init, and it would
>> be a compiler error to set a variable in the partial initializer that is
>> already set in the extension’s init without overriding the extension’s init.
>
>
> How can the compiler raise this error when the implementation of the
> partial initializer does not even have to exist at compile time?
>
> Example code:
>>
>> protocol P {
>>     var x: Int { let } // or { get set(init) }, or whatever
>>
>>     partialinit initializeRest()
>>     init()
>> }
>>
>> extension P {
>>     init() {
>>         initializeRest()
>>
>
> How can the compiler ensure that `initializeRest()` does not already set
> `x`?
>
>
>>         self.x = 1
>>     }
>> }
>>
>> struct S: P {
>>     let x: Int
>>     var y: String
>>
>>     // It would be a compiler error to set x here without also redefining
>> init()
>>     partialinit initializeRest() {
>>         self.y = “P has no knowledge of me”
>>     }
>>
>>     // Can use default init provided by P
>> }
>>
>> > On Jun 23, 2017, at 8:12 PM, Karl Wagner <razielim at gmail.com> wrote:
>> >
>> > What you want is some way to guarantee value semantics when writing
>> generic code.
>> >
>> > It’s a known hole, and admittedly quite a big one. I hope that there
>> will be time for core language improvements like this in Swift 5. Be sure
>> to raise the issue again once planning for that starts!
>> >
>> > - Karl
>> >
>> >> On 23. Jun 2017, at 23:43, Robert Bennett via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>
>> >> Hello Swift Evolution,
>> >>
>> >> I’m bumping into an annoying problem with protocols. In a class or
>> struct it is common to have a `let` instance variable and assign it in
>> `init`. Unfortunately there is no way to translate this into a protocol
>> with init in an extension. If attempting to set the variable in init in an
>> extension, it must be of type { get set }, which means it cannot be a `let`
>> constant in the conforming type. AFAIK there is no way around this — if you
>> want to set an instance variable in an initializer in a protocol extension,
>> it must be marked as { get set }. The alternative is to write the
>> initializer separately for each adopting type, but this violates DRY.
>> >>
>> >> Hence, I am proposing a third option to go along with `get` and `set`
>> in a protocol. This would indicate that the variable can be a constant, but
>> is settable in an initializer. In this case, the conforming type *must* use
>> `let` to declare the variable.
>> >>
>> >> Option 1: the keyword `let`. If present, it would need to be the only
>> thing in the curly brackets because it simultaneously implies `get` and not
>> `set`.
>> >>
>> >> protocol P {
>> >>   var x: Int { let }
>> >>   init(_ x: Int)
>> >>   func modifyX()
>> >> }
>> >> extension P {
>> >>   init(_ x: Int) {
>> >>       self.x = x // This is ok; would not be ok if x were marked { get
>> }
>> >>   }
>> >>
>> >>   func modifyX() {
>> >>       self.x += 1 // Not allowed
>> >>   }
>> >> }
>> >>
>> >> struct S: P {
>> >>   let x: Int // This is ok; would not be ok if x were marked { get set
>> }
>> >> }
>> >>
>> >> Option 2: `set(init)`. Can (and often will) coexist with `get`.
>> >>
>> >> protocol P {
>> >>   var x: Int { get set(init) }
>> >>   init(_ x: Int)
>> >>   func modifyX()
>> >> }
>> >> extension P {
>> >>   init(_ x: Int) {
>> >>       self.x = x // This is ok; would not be ok if x were marked { get
>> }
>> >>   }
>> >>
>> >>   func modifyX() {
>> >>       self.x += 1 // Not allowed
>> >>   }
>> >> }
>> >>
>> >> struct S: P {
>> >>   let x: Int // This is ok; would not be ok if x were marked { get set
>> }
>> >> }
>> >>
>> >>
>> >> I’d like to hear all of your thoughts on this.
>> >>
>> >> Best,
>> >> Robert
>> >> _______________________________________________
>> >> 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/20170625/aac037bb/attachment.html>