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

[David Owens II]

>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160124/84441e29/attachment.html>