[swift-evolution] Support for pure setters

[Jessy Catterwaul]

C# still hasn’t gotten named subscripts or tuples. It is not the place to go to look for what Swift should be. It’s just the only place I’ve had access to set-only properties, and because much of what I was doing was feeding data to GPUs, set-only properties made a lot of sense, frequently.

The most important thing is to not consider setting “writing”, or getting “reading”. Properties and subscripts are specifically “get” and “set”, and don’t enforce reading or writing any state. The book even gets the terminology wrong, as “read-only” instead of “get-only": https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html#//apple_ref/doc/uid/TP40014097-CH14-ID259

I understand that there is a lot of history in thinking about getters and setters as having something to do with storage, but that we have the keywords “get” and “set”, and not “read” and “write”, is guidance for cleaner APIs.


> On Feb 3, 2016, at 4:34 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> I would find a list of actual C# set-only properties more relevant. It wouldn't make sense for a lot of these "set-only properties" in there to offer only a setter if they were made into properties.
> 
> In general, I consider properties to be the observable state of an object. When I write something to a property, I expect to be able to get it back. When I pass something as a method parameter, I don't expect that I'll be able to get it back later.
> 
> Félix
> 
>> Le 3 févr. 2016 à 16:02:41, Jessy Catterwaul via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> I do not agree about the implication. A property can be gotten, set, or both, in at least C#, where I used a ton of set-only properties.
>> 
>> Here is a large list of properties that are set-only:
>> https://developer.apple.com/library/ios/documentation/Metal/Reference/MTLRenderCommandEncoder_Ref/index.html#//apple_ref/swift/intf/c:objc(pl)MTLRenderCommandEncoder <https://developer.apple.com/library/ios/documentation/Metal/Reference/MTLRenderCommandEncoder_Ref/index.html#//apple_ref/swift/intf/c:objc(pl)MTLRenderCommandEncoder>
>> 
>> Some of them require more than a single value, for setting. Tuple assignment or named subscripts are the best way I currently know to handle that. Having them be functions that begin with “set” and take arguments feels archaic and not specific enough, to me.
>> 
>> func setStencilFrontReferenceValue(frontReferenceValue: UInt32,
>>    backReferenceValue: UInt32
>> )
>> setStencilFrontReferenceValue(0, backReferenceValue: 1)
>> 
>> versus
>> 
>> var stencilReferenceValues: (front: UInt32, back: UInt32) {set}
>> stencilReferenceValues = (front: 0, back: 1)
>> 
>> 
>> func setVertexSamplerState(sampler: MTLSamplerState?, atIndex index: Int)
>> setVertexSamplerState(someState, atIndex 0)
>> 
>> versus
>> 
>> subscript vertexSamplerState(index: Int): MTLSamplerState? {set}
>> vertexSamplerState[0] = someState
>> 
>> 
>> The former options, I feel are not Swift, but C masquerading as Swift.
>> 
>> 
>> > Cc:swift-evolution at swift.org <mailto:evolution at swift.org>
>> > Subject:[swift-evolution] Support for pure setters
>> > Date:February 3, 2016 at 3:31:16 PM EST
>> > 
>> > 
>> > 
>> > > On Feb 3, 2016, at 12:21 PM, Jessy Catterwaul<mr.jessy at gmail.com <mailto:mr.jessy at gmail.com>>wrote:
>> > > 
>> > > Joe, to attempt to set foo.x doesn’t make sense. If foo cannot be gotten, a property of it will be inaccessible for getting or setting.
>> > > 
>> > > Set-only properties are always computed, and only used via assignment.
>> > > 
>> > > e.g. foo = value
>> > I understand that. If that's all you're allowed to do with a set-only property, then this is just sugar over 'setFoo(value)', and I think the sugar implies you could do more with 'foo' than you really can. I don't think it's worth the complexity.
>> > 
>> > -Joe
>> > 
>> > 
>> > 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160203/fefa2862/attachment.html>