[planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Mathew_Huusko_V]

Per
[swift-evolution-announce] [Update + Commentary] SE-0111: Remove type system significance of function argument labels,
the removal of parameter labels entirely was accepted as a temporary loss
for Swift 3 as a means to remove them from the type system. I'm wondering
if they're coming back (syntactically) any time soon?

Other than being in the spirit of Swift in general (safe APIs, first class
closures/functions), with the lack of optional protocol requirements the
only way to achieve something similar is..
`lazy var someFunc: ((someParam: String) -> String)? = { [unowned self]
someParam in ... }`
.. which doesn't compile anymore.

–––––––––––––––––––––––––––––––––––––––––––

As a related aside, I love Swift, and as it gains more core functionality
(e.g. KeyPaths) I love it even more. However I'm concerned that the systems
(frameworks *or* apps) I/others create on top of such functionality are
only as good as their APIs, which are often held back by the lack of
relevant features –
optional protocol requirements, within-module access (or at least,
*visibility*) control (e.g. ~protected), explicit/arbitrary
namespaces, abstract classes, currying, generalised existentials, factory
initialisers, closure parameter labels, etc.
– and it's concerning to read through swift-evolution and find a general
pattern of these features being postponed or worse, rejected, not because
of clear alternatives to producing the same *safe and expressive/explicit* APIs
they facilitate, but because ~"most programmers probably won't need/use
them".

This from/about the language that has tacked on a whole statement ('guard')
for inverse conditionals.
This from/about the language that is/has successfully popularised protocol
oriented programming, custom/overloaded operators, and ADTs.
This from/about the language that's supposed to define the next decade+ of
Apple and its (or more) community's software, as well as programming
education.

I think that if/when Swift accomplishes world domination (cc: Lattner), it
will find that the world is more diverse than has been let on, and the only
practical limit to what people will 'need'/find useful will be what Swift
was able to integrate safely/elegantly.

None of this would matter of course, or at least not so much, if it wasn't
for Swift's nearing target of ABI stability. Someone absolutely do feel
free to console me/tell me that all of these kinds of things (and things
that haven't been thought of yet; state of the art is a quickly moving
target after all..) could be added later if the community changes its mind,
but if not, that's scary. I understand the dangers of feature creep and
kitchen-sinkage, but C++ (e.g/etc.; TypeScript?) got the way it is by
reckless feature addition over multiple generations unchecked by ABI
stability requirements. Surely if there's only one main chance/generation
of feature addition with Swift, it should be relatively liberal/prescient.

Anyway, I've said/rambled more than enough/than I'm qualified to. TL;DR:/in
summary, some things are relatively small (closure parameter labels
probably won't define the future of the language) and some things.. aren't;
I hope that everything is being done to ensure that Swift can dominate the
world (and its diverse use cases)* currently* as well as hold that spot
when the standards/state of the art changes. I'd be really curious to hear
from core-esque people about their practical or lofty thoughts/feelings on
this matter.

[Chris_Lattner]

The planning approach for Swift 5 hasn’t been announced yet, but it should be soon-ish.

Responding to the rest of your email in broad terms: there will always be a ton of things that are important and interesting to tackle. There is also a long road ahead of Swift, so prioritization is not a bad thing: just because something doesn’t happen “now” doesn’t mean it never will.

I would also argue that it would be *bad* for the language to evolve too fast. Landing 20 major features all in the same year runs the very high risk that they doesn’t work well together and don’t have time to settle out properly. It is far more important for Swift to be great over the long term than to have any individual little feature “now”.

-Chris

···

On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution <swift-evolution@swift.org> wrote:

Per [swift-evolution-announce] [Update + Commentary] SE-0111: Remove type system significance of function argument labels, the removal of parameter labels entirely was accepted as a temporary loss for Swift 3 as a means to remove them from the type system. I'm wondering if they're coming back (syntactically) any time soon?

[Mathew_Huusko_V]

Thanks for the swift response, it's an honour; I agree wholeheartedly with
your logic and sentiment. Sorry if I was unclear, but my concern/curiosity
is not for the speed of Swift's development, but in fact for its long term
evolution and longevity. At risk of repeating myself/boring everyone, that
concern manifests over two intermingling phenomena:
1) in the evolution email/proposal archive, a well intentioned (towards
-complexity and +quality) but sometimes blasé air around potential
uses/requirements of the language (~"Swift won't support that because
people probably wouldn't use/need it").
2) the reality of the clock, or what I think/thought the reality was.
Obviously I don't want Swift to evolve too fast, and don't think having any
particular feature right now is worth risking that, but won't the ABI be
stabilised eventually (Swift 5?) and then it will actually be too late for
some features? Please correct me if I'm wrong here.

A possible (not sure if this is ABI bound) example:
As far as I've seen, optional protocol requirements (like 'protected',
private conformances, currying, etc.) are more off the table than
postponed, having been deemed an anti-pattern. Fair enough – I'm inclined
to trust the people involved in those discussions. But what if after ABI
stabilisation people get around to building some significant systems in
Swift (say, UIKit, which relies heavily on optional protocol requirements
for good reason) and don't find reasonable alternatives? There's no going
back, right?

···

On Fri, Aug 4, 2017 at 6:32 PM, Chris Lattner <clattner@nondot.org> wrote:

On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote:

Per https://lists.swift.org/pipermail/swift-evolution-announce/2
016-July/000233.html, the removal of parameter labels entirely was
accepted as a temporary loss for Swift 3 as a means to remove them from the
type system. I'm wondering if they're coming back (syntactically) any time
soon?

The planning approach for Swift 5 hasn’t been announced yet, but it should
be soon-ish.

Responding to the rest of your email in broad terms: there will always be
a ton of things that are important and interesting to tackle. There is
also a long road ahead of Swift, so prioritization is not a bad thing: just
because something doesn’t happen “now” doesn’t mean it never will.

I would also argue that it would be *bad* for the language to evolve too
fast. Landing 20 major features all in the same year runs the very high
risk that they doesn’t work well together and don’t have time to settle out
properly. It is far more important for Swift to be great over the long
term than to have any individual little feature “now”.

-Chris

[broomburgo (Elviro Rocca)]

I read many times the "most users don't care about this" objection but I always considered it more like an argument for postponing something than removing it completely from the Swift equation (I believe I also read words like that from yourself, Chris), because there is a point about scheduling work to make the language more useful for more people faster. I'm still acting upon the belief that the Swift core team recognizes that the language still lacks a lot of absolutely basic and essential features, that every "power user" that pushes the boundaries of what Swift has to offer can't wait for to be added.

I would argue that there are 2 kinds of features to be considered in the process of a language's evolution:

1) additions and improvements that augment the type/abstraction system and make the language itself more expressive;
2) utility tools like alternate declarations for identical concepts (like keywords that add some syntactic sugar) and enhancements to the standard library;

The difference between the two is the fact that the first allows users (including people that work on the standard library) to build better, more precise and sophisticated things with the language, while the second can make the language more useful and fun to use out-of-the-box by providing ready-made tools (for example, I'm glad that the standard library provides a "map" and "flatMap" for Optionals, and I 100% recognize the importance of syntactic sugar in many contexts, like for example keywords like async/await).

I would also argue that, while a prioritization strategy would probably favor the second type of features for the first years of a language's life, the effort in improving the language within the realm of the first type of features should still be constantly moving forward, along with everything else, if nothing because most of the second depends on the first.

For example, it we had conditional protocol conformances from the beginning (Swift 2), many aspects of the standard library and of many third-party library would be MASSIVELY different, and a lot of work of library-building would have been easier and faster.

I think these kinds of considerations are particularly important for Swift, because Swift is exactly the kind of language that can be molded to one developer's will, and doesn't overly push "conventions" like many more loosely-typed languages do: in a language as free to be interpreted as Swift, core features that enhance expressivity are, I think, the most important ones.

Thanks

Elviro

···

Il giorno 04 ago 2017, alle ore 19:32, Chris Lattner via swift-evolution <swift-evolution@swift.org> ha scritto:

On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Per [swift-evolution-announce] [Update + Commentary] SE-0111: Remove type system significance of function argument labels, the removal of parameter labels entirely was accepted as a temporary loss for Swift 3 as a means to remove them from the type system. I'm wondering if they're coming back (syntactically) any time soon?

The planning approach for Swift 5 hasn’t been announced yet, but it should be soon-ish.

Responding to the rest of your email in broad terms: there will always be a ton of things that are important and interesting to tackle. There is also a long road ahead of Swift, so prioritization is not a bad thing: just because something doesn’t happen “now” doesn’t mean it never will.

I would also argue that it would be *bad* for the language to evolve too fast. Landing 20 major features all in the same year runs the very high risk that they doesn’t work well together and don’t have time to settle out properly. It is far more important for Swift to be great over the long term than to have any individual little feature “now”.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

No. ABI stability is less of a bound of new things than it is a bound on the ability to change existing things.

To take one random example, C++ has been ABI stable on the Mac since effectively 10.0 (or whatever release first shipped GCC 3). That hasn’t impeded the ability to add tons of new stuff to C++. :-)

-Chris

···

On Aug 4, 2017, at 12:03 PM, Mathew Huusko V <mhuusko5@gmail.com> wrote:

Thanks for the swift response, it's an honour; I agree wholeheartedly with your logic and sentiment. Sorry if I was unclear, but my concern/curiosity is not for the speed of Swift's development, but in fact for its long term evolution and longevity. At risk of repeating myself/boring everyone, that concern manifests over two intermingling phenomena:
1) in the evolution email/proposal archive, a well intentioned (towards -complexity and +quality) but sometimes blasé air around potential uses/requirements of the language (~"Swift won't support that because people probably wouldn't use/need it").
2) the reality of the clock, or what I think/thought the reality was. Obviously I don't want Swift to evolve too fast, and don't think having any particular feature right now is worth risking that, but won't the ABI be stabilised eventually (Swift 5?) and then it will actually be too late for some features?

[Mathew_Huusko_V]

Ah, I see. I understood on a basic level that additive features were safe,
but I didn't/don't have the knowledge to judge when adding actually means
changing (e.g. idk, 'adding abstract classes' or 'adding optional protocol
methods' implying 'changing/breaking inheritance/dispatch' or something..).

Anyway, I didn't know that about C++ – now *that's *a reassuring benchmark.
Thanks! ;)

···

On Fri, Aug 4, 2017 at 8:46 PM, Chris Lattner <clattner@nondot.org> wrote:

> On Aug 4, 2017, at 12:03 PM, Mathew Huusko V <mhuusko5@gmail.com> wrote:
>
> Thanks for the swift response, it's an honour; I agree wholeheartedly
with your logic and sentiment. Sorry if I was unclear, but my
concern/curiosity is not for the speed of Swift's development, but in fact
for its long term evolution and longevity. At risk of repeating
myself/boring everyone, that concern manifests over two intermingling
phenomena:
> 1) in the evolution email/proposal archive, a well intentioned (towards
-complexity and +quality) but sometimes blasé air around potential
uses/requirements of the language (~"Swift won't support that because
people probably wouldn't use/need it").
> 2) the reality of the clock, or what I think/thought the reality was.
Obviously I don't want Swift to evolve too fast, and don't think having any
particular feature right now is worth risking that, but won't the ABI be
stabilised eventually (Swift 5?) and then it will actually be too late for
some features?

No. ABI stability is less of a bound of new things than it is a bound on
the ability to change existing things.

To take one random example, C++ has been ABI stable on the Mac since
effectively 10.0 (or whatever release first shipped GCC 3). That hasn’t
impeded the ability to add tons of new stuff to C++. :-)

-Chris

[Chris_Lattner]

Yes, there is a really huge amount of stuff that is missing from Swift. I suspect my list is longer than anyone else’s. :-)

My point on this is that it is more important to get the big efforts right than it is to over-prioritize the small efforts. This is both because of implementation bandwidth reasons, but more importantly because it leads to a better design. Big efforts are *hard*, and tend to be less driven by the community at large, but they really should take priority.

If you’re into analogies, I see features like the generics improvements, concurrency model, ownership system, macro system, ABI stability, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, smaller proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.

Clearly there is a balance to be made, which is why major Swift releases are a mix of large efforts (e.g. Codable improvements, typed keypaths, String redesign...) as well as smaller ones (e.g. multiline strings, dictionary API improvements, etc).

-Chris

···

On Aug 7, 2017, at 12:43 AM, Elviro Rocca <retired.hunter.djura@gmail.com> wrote:

I read many times the "most users don't care about this" objection but I always considered it more like an argument for postponing something than removing it completely from the Swift equation (I believe I also read words like that from yourself, Chris), because there is a point about scheduling work to make the language more useful for more people faster. I'm still acting upon the belief that the Swift core team recognizes that the language still lacks a lot of absolutely basic and essential features, that every "power user" that pushes the boundaries of what Swift has to offer can't wait for to be added.

[taylorswift]

The FSA drama is a good example of this. You could either create a special
new syntax for them, or extend the generics system to take value
parameters. Then again there is a problem where people use that as an
excuse to procrastinate on a feature.

···

On Mon, Aug 7, 2017 at 12:12 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

> On Aug 7, 2017, at 12:43 AM, Elviro Rocca <retired.hunter.djura@gmail. > > wrote:
>
> I read many times the "most users don't care about this" objection but I
always considered it more like an argument for postponing something than
removing it completely from the Swift equation (I believe I also read words
like that from yourself, Chris), because there is a point about scheduling
work to make the language more useful for more people faster. I'm still
acting upon the belief that the Swift core team recognizes that the
language still lacks a lot of absolutely basic and essential features, that
every "power user" that pushes the boundaries of what Swift has to offer
can't wait for to be added.

Yes, there is a really huge amount of stuff that is missing from Swift. I
suspect my list is longer than anyone else’s. :-)

My point on this is that it is more important to get the big efforts right
than it is to over-prioritize the small efforts. This is both because of
implementation bandwidth reasons, but more importantly because it leads to
a better design. Big efforts are *hard*, and tend to be less driven by the
community at large, but they really should take priority.

If you’re into analogies, I see features like the generics improvements,
concurrency model, ownership system, macro system, ABI stability, new
frameworks, and other large scale efforts as the “bricks" that make up the
house of Swift. In that analogy, smaller proposals are “mortar” that fills
in the cracks between the bricks. If we add too much mortar too early on,
we run the risk of the house of Swift being built out of mortar, or of not
being able to fit the bricks into the right places. That would be very
bad, given that we all want the house of Swift to be strong and beautiful
over the long term.

Clearly there is a balance to be made, which is why major Swift releases
are a mix of large efforts (e.g. Codable improvements, typed keypaths,
String redesign...) as well as smaller ones (e.g. multiline strings,
dictionary API improvements, etc).

-Chris

[broomburgo (Elviro Rocca)]

I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction:

- big efforts that add huge new features to the language so that things that were done in userland with libraries can be done natively and idiomatically (concurrent programming, for example);
- more "theoretical" big efforts, that allow one, while building a single app or a big library, to "express" more things more precisely in the language, and improvements to the generics and protocols systems fall in this second realm;

The reason why I consider the second kind of feature as more important than the first (thus, earning higher priority) is that, apart from reducing the amount of busywork to be done in many cases where the abstraction power is not good enough, it gives more tools for the community to build upon, it allows many people to do more with the language than probably me, you and the core team have ever though of, it fosters the explosion of creativity that's only possible when a language is expressive enough and it's not only based on certain conventions (that, by definition, constraint the way a language is commonly used).

What do you think?

Thanks

Elviro

···

Il giorno 07 ago 2017, alle ore 18:11, Chris Lattner <clattner@nondot.org> ha scritto:

On Aug 7, 2017, at 12:43 AM, Elviro Rocca <retired.hunter.djura@gmail.com> wrote:

I read many times the "most users don't care about this" objection but I always considered it more like an argument for postponing something than removing it completely from the Swift equation (I believe I also read words like that from yourself, Chris), because there is a point about scheduling work to make the language more useful for more people faster. I'm still acting upon the belief that the Swift core team recognizes that the language still lacks a lot of absolutely basic and essential features, that every "power user" that pushes the boundaries of what Swift has to offer can't wait for to be added.

Yes, there is a really huge amount of stuff that is missing from Swift. I suspect my list is longer than anyone else’s. :-)

My point on this is that it is more important to get the big efforts right than it is to over-prioritize the small efforts. This is both because of implementation bandwidth reasons, but more importantly because it leads to a better design. Big efforts are *hard*, and tend to be less driven by the community at large, but they really should take priority.

If you’re into analogies, I see features like the generics improvements, concurrency model, ownership system, macro system, ABI stability, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, smaller proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.

Clearly there is a balance to be made, which is why major Swift releases are a mix of large efforts (e.g. Codable improvements, typed keypaths, String redesign...) as well as smaller ones (e.g. multiline strings, dictionary API improvements, etc).

-Chris

[Tino]

If you’re into analogies, I see features like the generics improvements, concurrency model, ownership system, macro system, ABI stability, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, smaller proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.

I really like this image — especially because it shows the need for a third ingredient:
Even with a perfect mixture of mortar and bricks, you'll end up with little more than a pile of rocks and clay if you don't have some kind of blueprint.

Of course, an analogy is just analogy, but I think especially under the light of the change of rules for the evolution process, it is even more important to have a bigger picture of the future Swift:
Instead of people just arguing for their favourite type of block to be integrated as soon as possible, I'd like to see more guidance on which additions fit into the plan, and how they interact with each other.
Not only because this might protected people from wasting their time with shaping the wrong bricks, but also to increase consistency in the language.

- Tino

[Chris_Lattner]

MHO is that both are important. I think the details of the tradeoffs involved prioritizing the individual members of those categories are bigger than the difference between the two categories. I don’t think this is a useful way to try to slice the problem up.

-Chris

···

On Aug 7, 2017, at 11:34 PM, Elviro Rocca <retired.hunter.djura@gmail.com> wrote:

I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction:

- big efforts that add huge new features to the language so that things that were done in userland with libraries can be done natively and idiomatically (concurrent programming, for example);
- more "theoretical" big efforts, that allow one, while building a single app or a big library, to "express" more things more precisely in the language, and improvements to the generics and protocols systems fall in this second realm;

The reason why I consider the second kind of feature as more important than the first (thus, earning higher priority) is that, apart from reducing the amount of busywork to be done in many cases where the abstraction power is not good enough, it gives more tools for the community to build upon, it allows many people to do more with the language than probably me, you and the core team have ever though of, it fosters the explosion of creativity that's only possible when a language is expressive enough and it's not only based on certain conventions (that, by definition, constraint the way a language is commonly used).

[Mathew_Huusko_V]

Sorry to revive this, but back on my ABI stability education:

Swift 5 planning was announced today (woohoo!) with a primary target on ABI
stability. Finalising generics seems to be a major part of this, with
"conditional conformances", "recursive protocol requirements," and "there
are no known other generics enhancements needed for ABI stability" as key
points.

But it seems like there's quite a bit more left in the generics manifesto
unimplemented. Perhaps some of what's in there is controversial, but
something like generalised existentials afaik *is/was* planned.. can
someone explain how GE doesn't affect ABI stability?
To my very naive mind it's not that different from some other things said
to affect ABI, and to my slightly less naive mind, I believe it was going
to enable a protocol oriented approach to KeyPaths in the future, which
seems like it would affect ABI of stdlib.

I'm quite sure I'm missing the core concept at this point, so I'd be
content with my examples being ignored and just pointing me towards a
general/educational resource on ABI vs. interface thats vaguely compatible
with Swift.

Thanks!

···

On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner <clattner@nondot.org> wrote:

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca < > retired.hunter.djura@gmail.com> wrote:
>
> I agree with everything you wrote, in particular I agree with the idea
that it is more important to get the big efforts right, and that they
should take priority. But I would consider a distinction:
>
> - big efforts that add huge new features to the language so that things
that were done in userland with libraries can be done natively and
idiomatically (concurrent programming, for example);
> - more "theoretical" big efforts, that allow one, while building a
single app or a big library, to "express" more things more precisely in the
language, and improvements to the generics and protocols systems fall in
this second realm;
>
> The reason why I consider the second kind of feature as more important
than the first (thus, earning higher priority) is that, apart from reducing
the amount of busywork to be done in many cases where the abstraction power
is not good enough, it gives more tools for the community to build upon, it
allows many people to do more with the language than probably me, you and
the core team have ever though of, it fosters the explosion of creativity
that's only possible when a language is expressive enough and it's not only
based on certain conventions (that, by definition, constraint the way a
language is commonly used).

MHO is that both are important. I think the details of the tradeoffs
involved prioritizing the individual members of those categories are bigger
than the difference between the two categories. I don’t think this is a
useful way to try to slice the problem up.

-Chris

[Michael_Ilseman]

The key difference is whether such things can be rolled out in the future in an additive way, potentially with extra compatibility affordances, vs whether something is inherent to the ABI as Swift and the standard library currently exists. This is a very fuzzy line, and is constantly getting reevaluated. But, generics features that change fundamental standard library internals such as Collection’s associated types fall more on the affects-current-ABI side of things, while additions that expose potential for new and better APIs fall on the ABI-additive side of things.

New and improved existential-backed APIs can be added while keeping around (or even deprecating) the older ones, but existing protocol hierarchies and their associated types can’t be easily uprooted. I apologize that this doesn’t shed a ton of light on the difference, but these things exist on a case-by-case basis.

···

On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution <swift-evolution@swift.org> wrote:

Sorry to revive this, but back on my ABI stability education:

Swift 5 planning was announced today (woohoo!) with a primary target on ABI stability. Finalising generics seems to be a major part of this, with "conditional conformances", "recursive protocol requirements," and "there are no known other generics enhancements needed for ABI stability" as key points.

But it seems like there's quite a bit more left in the generics manifesto unimplemented. Perhaps some of what's in there is controversial, but something like generalised existentials afaik *is/was* planned.. can someone explain how GE doesn't affect ABI stability?
To my very naive mind it's not that different from some other things said to affect ABI, and to my slightly less naive mind, I believe it was going to enable a protocol oriented approach to KeyPaths in the future, which seems like it would affect ABI of stdlib.

I'm quite sure I'm missing the core concept at this point, so I'd be content with my examples being ignored and just pointing me towards a general/educational resource on ABI vs. interface thats vaguely compatible with Swift.

Thanks!

On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca <retired.hunter.djura@gmail.com <mailto:retired.hunter.djura@gmail.com>> wrote:
>
> I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction:
>
> - big efforts that add huge new features to the language so that things that were done in userland with libraries can be done natively and idiomatically (concurrent programming, for example);
> - more "theoretical" big efforts, that allow one, while building a single app or a big library, to "express" more things more precisely in the language, and improvements to the generics and protocols systems fall in this second realm;
>
> The reason why I consider the second kind of feature as more important than the first (thus, earning higher priority) is that, apart from reducing the amount of busywork to be done in many cases where the abstraction power is not good enough, it gives more tools for the community to build upon, it allows many people to do more with the language than probably me, you and the core team have ever though of, it fosters the explosion of creativity that's only possible when a language is expressive enough and it's not only based on certain conventions (that, by definition, constraint the way a language is commonly used).

MHO is that both are important. I think the details of the tradeoffs involved prioritizing the individual members of those categories are bigger than the difference between the two categories. I don’t think this is a useful way to try to slice the problem up.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Douglas_Gregor]

Sorry to revive this, but back on my ABI stability education:

[We’re a bit far afield of the original subject, but okay]

Swift 5 planning was announced today (woohoo!) with a primary target on ABI stability. Finalising generics seems to be a major part of this, with "conditional conformances", "recursive protocol requirements," and "there are no known other generics enhancements needed for ABI stability" as key points.

But it seems like there's quite a bit more left in the generics manifesto unimplemented.

Right. We’re not going to get to all of this in a year, or two years, and we don’t get to block ABI stability on all of the features therein.

Perhaps some of what's in there is controversial, but something like generalised existentials afaik *is/was* planned.. can someone explain how GE doesn't affect ABI stability?

It’s an additive feature, so it doesn’t *change* the ABI per se, it extends the ABI to describe something it didn’t describe before. Now, there are a few places where we could still run into ABI-compatibility issues when adding something new:

* Generalized existentials are a new structural type. An old runtime will not understand the type metadata for these types, so we have to deal with that in some way. Sometimes we can “implement ahead”, providing support for a a feature in the runtime that isn’t surfaced in the language itself yet, or we can try to build in future-proof mechanisms for adding more types.

* Generalized existentials could change the way the standard library works or is implemented. This is mostly opportunity cost: if we don’t have the feature, we’ll have some suboptimal-in-retrospect APIs or implementation that’s baked into the standard library. For generalized existentials, we’re likely to have some suboptimality with struct AnyCollection, either in the implementation (it could wrap a “Collection where .Element == Element”) or even in the API itself (maybe the struct should go away and it should be a typealias for the corresponding generalized existential).

To my very naive mind it's not that different from some other things said to affect ABI, and to my slightly less naive mind, I believe it was going to enable a protocol oriented approach to KeyPaths in the future, which seems like it would affect ABI of stdlib.

Every ABI is suboptimal. Once you’ve shipped it, there are some hard limits on what you can change (because all of the existing binaries need to continue to work), but it’s still possible to make improvements. At worst, the improvements only be available on some future OS. Sometimes, one can do better by putting more work into the implementation to interoperate with other binaries, and often language runtime designers leave themselves hooks that allow such improvements in the future. We’ll do some of this in the Swift ABI, particularly where we expect change. Engineering trade-offs abound, and for generics, we feel like we can tackle what’s been proposed already… but not more… and that we can live with the limitations posed by that model.

I'm quite sure I'm missing the core concept at this point, so I'd be content with my examples being ignored and just pointing me towards a general/educational resource on ABI vs. interface thats vaguely compatible with Swift.

The ABI Dashboard (https://swift.org/abi-stability/\) and ABI Manifesto (https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md\) cover some of this.

  - Doug

···

On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution <swift-evolution@swift.org> wrote:

Thanks!

On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca <retired.hunter.djura@gmail.com <mailto:retired.hunter.djura@gmail.com>> wrote:
>
> I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction:
>
> - big efforts that add huge new features to the language so that things that were done in userland with libraries can be done natively and idiomatically (concurrent programming, for example);
> - more "theoretical" big efforts, that allow one, while building a single app or a big library, to "express" more things more precisely in the language, and improvements to the generics and protocols systems fall in this second realm;
>
> The reason why I consider the second kind of feature as more important than the first (thus, earning higher priority) is that, apart from reducing the amount of busywork to be done in many cases where the abstraction power is not good enough, it gives more tools for the community to build upon, it allows many people to do more with the language than probably me, you and the core team have ever though of, it fosters the explosion of creativity that's only possible when a language is expressive enough and it's not only based on certain conventions (that, by definition, constraint the way a language is commonly used).

MHO is that both are important. I think the details of the tradeoffs involved prioritizing the individual members of those categories are bigger than the difference between the two categories. I don’t think this is a useful way to try to slice the problem up.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Mathew_Huusko_V]

Perfect, thanks!

···

On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor <dgregor@apple.com> wrote:

On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote:

Sorry to revive this, but back on my ABI stability education:

[We’re a bit far afield of the original subject, but okay]

Swift 5 planning was announced today (woohoo!) with a primary target on
ABI stability. Finalising generics seems to be a major part of this, with
"conditional conformances", "recursive protocol requirements," and "there
are no known other generics enhancements needed for ABI stability" as key
points.

But it seems like there's quite a bit more left in the generics manifesto
unimplemented.

Right. We’re not going to get to all of this in a year, or two years, and
we don’t get to block ABI stability on all of the features therein.

Perhaps some of what's in there is controversial, but something like
generalised existentials afaik *is/was* planned.. can someone explain how
GE doesn't affect ABI stability?

It’s an additive feature, so it doesn’t *change* the ABI per se, it
extends the ABI to describe something it didn’t describe before. Now, there
are a few places where we could still run into ABI-compatibility issues
when adding something new:

* Generalized existentials are a new structural type. An old runtime will
not understand the type metadata for these types, so we have to deal with
that in some way. Sometimes we can “implement ahead”, providing support for
a a feature in the runtime that isn’t surfaced in the language itself yet,
or we can try to build in future-proof mechanisms for adding more types.

* Generalized existentials could change the way the standard library works
or is implemented. This is mostly opportunity cost: if we don’t have the
feature, we’ll have some suboptimal-in-retrospect APIs or implementation
that’s baked into the standard library. For generalized existentials, we’re
likely to have some suboptimality with struct AnyCollection, either in the
implementation (it could wrap a “Collection where .Element == Element”) or
even in the API itself (maybe the struct should go away and it should be a
typealias for the corresponding generalized existential).

To my very naive mind it's not that different from some other things said
to affect ABI, and to my slightly less naive mind, I believe it was going
to enable a protocol oriented approach to KeyPaths in the future, which
seems like it would affect ABI of stdlib.

Every ABI is suboptimal. Once you’ve shipped it, there are some hard
limits on what you can change (because all of the existing binaries need to
continue to work), but it’s still possible to make improvements. At worst,
the improvements only be available on some future OS. Sometimes, one can do
better by putting more work into the implementation to interoperate with
other binaries, and often language runtime designers leave themselves hooks
that allow such improvements in the future. We’ll do some of this in the
Swift ABI, particularly where we expect change. Engineering trade-offs
abound, and for generics, we feel like we can tackle what’s been proposed
already… but not more… and that we can live with the limitations posed by
that model.

I'm quite sure I'm missing the core concept at this point, so I'd be
content with my examples being ignored and just pointing me towards a
general/educational resource on ABI vs. interface thats vaguely compatible
with Swift.

The ABI Dashboard (https://swift.org/abi-stability/\) and ABI Manifesto (
https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md\)
cover some of this.

- Doug

Thanks!

On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner <clattner@nondot.org> wrote:

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca < >> retired.hunter.djura@gmail.com> wrote:
>
> I agree with everything you wrote, in particular I agree with the idea
that it is more important to get the big efforts right, and that they
should take priority. But I would consider a distinction:
>
> - big efforts that add huge new features to the language so that things
that were done in userland with libraries can be done natively and
idiomatically (concurrent programming, for example);
> - more "theoretical" big efforts, that allow one, while building a
single app or a big library, to "express" more things more precisely in the
language, and improvements to the generics and protocols systems fall in
this second realm;
>
> The reason why I consider the second kind of feature as more important
than the first (thus, earning higher priority) is that, apart from reducing
the amount of busywork to be done in many cases where the abstraction power
is not good enough, it gives more tools for the community to build upon, it
allows many people to do more with the language than probably me, you and
the core team have ever though of, it fosters the explosion of creativity
that's only possible when a language is expressive enough and it's not only
based on certain conventions (that, by definition, constraint the way a
language is commonly used).

MHO is that both are important. I think the details of the tradeoffs
involved prioritizing the individual members of those categories are bigger
than the difference between the two categories. I don’t think this is a
useful way to try to slice the problem up.

-Chris

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Alexey (Alexey Kravchenko)]

Any news about closure parameter labels? Should we restart this discussion now in perspective of Swift 5?

[DevAndArtist (Adrian Meister)]

You can jump into the discussion thread here.

[Alexey (Alexey Kravchenko)]

Thanks