[swift-evolution] Allowing Characters for use as Custom Operators
dennis.s.lysenko at gmail.com
Sun Jan 10 00:34:17 CST 2016
Sorry Chris, seems as though I misinterpreted. I guess I was arguing the
principle more than the specific example here; apologies if I derailed the
thread a bit. At the risk of derailing the thread further, since I still
have your attention and am not sure where else to raise such a suggestion:
have you or other members of the Swift team considered talking to the team
behind Kotlin? Kotlin has been loosely touted as "Swift for the
JVM/android" and may share some motivation with Swift--modern functionality
and interoperability with a very well-known, older language. In spite of
how much the two languages differ in key areas, maybe the two teams could
share and discuss motivation behind previous language decisions. Not sure
if there is a precedent for that kind of interaction so feel free to
On Sun, Jan 10, 2016, 12:30 AM Chris Lattner <clattner at apple.com> wrote:
> On Jan 9, 2016, at 7:50 PM, Dennis Lysenko <dennis.s.lysenko at gmail.com>
> Chris, perhaps there is a disconnect in our perceptions of the commonly
> proposed list. Based on the way you and others have referenced the commonly
> proposed list, it comes off as a blacklist of sorts. That is, "it's on the
> commonly proposed list" seems to be seen as an argument against a proposal.
> I only worry that the mere presence of something on the commonly proposed
> list will serve as a deterrent to legitimate proposals involving it in the
> Hi Dennis,
> I’m sorry for the confusion on this. The very first paragraph of that
> page says:
> … If you're interested in pursuing something in this space, please
> familiarize yourself with the discussions that we have already had. In
> order to bring one of these topics up, you'll be expected to add new
> information to the discussion, not just say "I really want this" or "This
> exists in some other language and I liked it there".
> The intention is to avoid re-treading old ground, not to say that
> something is impossible.
> If you have taken that into consideration when deciding to place infix
> functions on the commonly proposed list then fair enough. I just feel that
> infix functions have not been discussed nearly as much as, say,
> "indentation over brace syntax" or "getting rid of ternary", and it's a bit
> preemptive to put such a dent in potential future discussion because you
> personally cannot imagine a use case warranting the language change.
> Out of curiosity, has there even been a top-level proposal for infix
> functions that generated significant discussion?
> Yes, it has come up several times in different contexts. The advantage of
> “x foo bar” (potentially with sigils around foo) over “x.foo(bar)” has
> consistently been seen as not worth adding complexity for. Perhaps you are
> thinking of something else?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution