> On Jul 1, 2016, at 8:25 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > > * I think we need the word "localized" on the properties of `LocalizedError`. > The fact that they're localized is a very important semantic, and I don't > think the fact that they come from a protocol called "Localized" is enough to > signal that at use sites. (With "localized" added, `errorDescription` would > no longer need the vacuous word "error" to avoid colliding with > `CustomStringConvertible`.)
I disagree, for a few reasons: 1. The most common user of this protocol is the person implementing conformance for it. “Localized” is right up there in the protocol name, which usually won’t be far from the declarations of these properties. Repeating it in all the property names seems redundant and unnecessarily verbose, and very much not in keeping with the general feel of Swift 3. 2. The word “error” would need to be kept in “errorDescription” anyway, since simply renaming it “localizedDescription” would cause it to conflict with the property that is being added to ErrorProtocol itself. It would probably need to be named “localizedErrorDescription” or some such, which is really getting too long. 3. I’ve always felt the “Localized” in all those constant names was unnecessary, even in the old Objective-C API. Isn’t it kind of a given that a user-facing string should be localized? Why would you ever want a non-localized error description, failure reason, etc. in the first place? Should we add “localized” to the beginnings of, for example, NSAlert’s ‘messageText' and ‘informativeText' properties? Those properties certainly should be localized. How about NSSavePanel’s ‘prompt’ property? IMO, it’s unnecessary verbiage. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
