[swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines

David Owens II david at owensd.io
Sun Jan 24 19:11:37 CST 2016


Sorry, I meant to add the do() version too in order to show the difference better. /sigh


> On Jan 24, 2016, at 4:53 PM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> I guess my point is this: codifying a convention seems pre-mature as
>>> that convention doesn't bring the safety goals of the language into a
>>> place that's verifiable. All of the other guidelines are simply about
>>> clarity of use, this convention has a far reaching impact.
>> 
>> Sorry, could you clarify what you mean by "bring the safety goals of the
>> language into a place that's verifiable" and clarify why having a "far
>> reaching impact" would somehow conflict with being "about clarity of use?"
>> 
>> It seems to me that this convention is about how to express whether a
>> method is going to mutate so it's clear at the use-site.  What am I
>> missing?
> 
> 
> The problem is it's unclear to me whether you mean mutate in the true sense of the word or only applied to a struct with a function annotated with the mutating keyword.
> 
> The naming convention provides no safety when dealing with non-struct types as we cannot enforce that a method on a class does not mutate it's internal members.
> 
> That's the clarity I'm looking for.
> 
> Given this API set:
> 
> protocol InPlaceable {
>     mutating func doInPlace()
> }
> 
> public struct Foo: InPlaceable {
>     mutating func doInPlace() {}
> }
> 
> public class Bar: InPlaceable {
>     func doInPlace() {}
> }
> 
> var lie: InPlaceable = Bar()
> lie.doInPlace()
> 
> let lie2 = Bar()
> lie2.doInPlace()
> 
> The convention will tell us a lie unless we are extremely careful. It's this lie that concerns me. We cannot guarantee that the "doInPlace" truly matches the definition we are seeking.
> 
> 
> -David
> _______________________________________________
> 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/20160124/c6b69796/attachment.html>


More information about the swift-evolution mailing list