> On Jun 29, 2016, at 9:37 AM, Matthew Johnson <[email protected]> wrote: > >> >> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution >> <[email protected]> wrote: >> I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, >> where >> `select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` >> offers >> a substitutable alias for fp aficionados. >> This approach is not anything I've ever seen previously in a programming >> language but >> its something that jumps out as a way to satisfy two distinct audiences of >> users >> that would have limited impact but a decided advantage. > > Aliasing methods is pretty common in Ruby. The advantage is that you can > select the alias that reads best at a specific call site. The disadvantage > is that everyone has to learn more than one name for the same thing. > > If we’re going to allow aliases I think it should be in support of clarity at > specific call sites. I think the hurdle for this is pretty high and I’m not > sure we would find the benefits to outweigh the drawbacks, but it is a > discussion we could have. I would want to see concrete examples (which could > be drawn from Ruby code). > > I don’t think we should do this just to support term-of-art aliases where we > believe we have a different name that fits Swift better. This creates > “dialects” which I believe is a stated anti-goal of Swift. > > It may turn out that existing terms of art provide enhanced clarity in some > contexts and more Swifty names in others, in which case the alias may make > sense. But it if we add them it should be done on the grounds of clarity and > be accompanied by guidelines regarding which name to choose. > > But my hunch is that this introduces more complexity than value.
Don't forget QuickHelp and module interfaces, which automatically list attributes along with the declaration.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
