[swift-evolution] Support for pure setters

[Félix Cloutier]

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> 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
> 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/081aeadd/attachment.html>