<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">I think there might be some merit to this pitch, since you brought up a particular weak spot. I’d have to see what other people say about this, but it would seem that having the ability to explicitly mark something as constant for a given protocol implementation. 
<div><br /></div>
<div>However, I would propose a change to the syntax you gave as an example, since it isn’t quite clear when it comes to the implementation. I think just a simple `let foo: Bar` would suffice, unless I’m missing some particular component of your concept.</div>
<div><br /></div>
<div>This would allow extensions to operate on known constant values, perhaps improving performance maybe.</div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
On Jun 23, 2017, 5:49 PM -0400, Robert Bennett via swift-evolution <swift-evolution@swift.org>, wrote:<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">Hello Swift Evolution,<br />
<br />
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.<br />
<br />
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.<br />
<br />
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`.<br />
<br />
protocol P {<br />
var x: Int { let }<br />
init(_ x: Int)<br />
func modifyX()<br />
}<br />
extension P {<br />
init(_ x: Int) {<br />
self.x = x // This is ok; would not be ok if x were marked { get }<br />
}<br />
<br />
func modifyX() {<br />
self.x += 1 // Not allowed<br />
}<br />
}<br />
<br />
struct S: P {<br />
let x: Int // This is ok; would not be ok if x were marked { get set }<br />
}<br />
<br />
Option 2: `set(init)`. Can (and often will) coexist with `get`.<br />
<br />
protocol P {<br />
var x: Int { get set(init) }<br />
init(_ x: Int)<br />
func modifyX()<br />
}<br />
extension P {<br />
init(_ x: Int) {<br />
self.x = x // This is ok; would not be ok if x were marked { get }<br />
}<br />
<br />
func modifyX() {<br />
self.x += 1 // Not allowed<br />
}<br />
}<br />
<br />
struct S: P {<br />
let x: Int // This is ok; would not be ok if x were marked { get set }<br />
}<br />
<br />
<br />
I’d like to hear all of your thoughts on this.<br />
<br />
Best,<br />
Robert<br />
_______________________________________________<br />
swift-evolution mailing list<br />
swift-evolution@swift.org<br />
https://lists.swift.org/mailman/listinfo/swift-evolution<br /></blockquote>
</div>
</body>
</html>