[swift-evolution] Take 2: Stdlib closure argument labels and parameter names

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 11:19 AM, Sean Heber <sean at fifthace.com> wrote:

> > Agreed. I'd have to be convinced that having aliases provide
> overwhelming wins at the call site that could not be achieved through
> renaming. Although aliasing could be very neat in certain circumstances, I
> fear that admitting such a facility to the language is an "out" that would
> discourage exploration of the most appropriate method names and
> consensus-building in favor of "you'll have yours and I'll have mine,"
> which would be fatal for building a coherent set of APIs.
>
> It would probably be quite difficult to prove (although that doesn’t mean
> it isn’t worth trying) that aliases would be an overwhelming win because
> everyone has different tolerances for impedance mismatches. In many ways,
> it is that difference of tolerance that is the issue here (and in a few
> other threads).
>
> I personally have no desire to fragment things more than necessary, but I
> also really want code to read fluently. These goals seem to be at odds and,
> I speculate, they are at odds in ways that are impossible to solve with a
> single solution. Human languages have a lot of redundancy and variety for a
> reason, and we’ve taken the stance that Swift should read with a kind of
> “flow” that we usually only associate with human languages. This means that
> there are likely going to have to be concessions made to Swift that one
> might not ordinarily see in a programming language. (IMO)
>

I disagree with your interpretation of "Swifty" here. I understand the
supreme aim for Swift naming to be clarity, especially at the call site. In
some places, that would require Obj-C/Cocoa-like verbosity; in others it
calls for terseness. In some places, it should read more "fluently", in
others not as much (e.g. arguments inside `init()` omit the classic
preposition "with"). So I would disagree that we should make concessions to
"fluency" but rather to clarity. And as for clarity, two names for the same
thing are, ipso facto, less clear than one, which is why I argue that the
wins would have to be "overwhelming".


> The argument that aliases would be “fatal” for building coherent API
> doesn’t seem to tell the whole story to me. After all, every program
> ultimately has it’s own “language” of sorts that is built up from the
> building blocks of the standard library and other included frameworks.
> There’s a unique mix of the usage of certain words, constructs, names in
> each program that is a reflection of the programmers who have built the
> program and each one reads differently no matter how hard we might try to
> have only “one true way” to express a thing.
>

I was more writing in relation to the topics discussed here--i.e. stdlib
and corelibs naming--and not so much in relation to user code. Within an
API, I'd argue there should very much be only one "language", especially
given that any particular program may ultimately use many frameworks, since
one "language" from each framework could already be a lot to handle.


>
> To me, one of the nicer aspects of having aliases encoded in the API as
> function attributes is that, in the case of the standard libraries, they
> would be decided and bikeshedded by the usual suspects and then effectively
> locked into place. There’s still control on the extent of use of this
> feature. You cannot add an alias by way of an extension in your own code,
> for example, and I think that’s a fine tradeoff. It would be surgically
> used and, mostly, only by the core team/standard lib API designers and by
> those who wish to experiment. I don’t know if that’s a big win or not. To
> me, this feels like mostly untested territory.
>

See, here I would be precisely against that use for aliasing. For your own
code and as an extension, maybe. But as I argue above, definitely not for
stdlib and definitely not at the point of declaration.


> l8r
> Sean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/4de22bd9/attachment.html>