Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
I'm sure the implementation is fine, and I'm not criticising the proposal's
intent/concept, least of all simply because it might be misused (because
everything can and is).
Instead, I firmly believe — not to say I necessarily *deserve* a contrary
explanation/argument if no one thinks this is a big deal, but just to be
clear.. — that it is clean but fundamentally misleading (and thus
potentially non-ergonomic) to transparently convert `Python.open(filename)`
to `Python.get(member: "open")(filename)`.
The former line reads as "this lines calls this Swift function the compiler
knows exists, as usual", and the latter reads as "this line looks for/tries
to call something that may exist" — two very/importantly different things,
and you will only be able to tell the difference by option-clicking the
call site.
When we want to deal with a value that may not exist at runtime (an
optional), there's extra syntax ('?') for that. It seems like the same
thing for a function/call that may not exist *might* be appropriate.
Equally happy to hear why not.
On Mon, Nov 27, 2017 at 6:30 PM, Chris Lattner wrote:
> On Nov 27, 2017, at 6:37 AM, Mathew Huusko V wrote:
> > I tuned out the initial discussions of this proposal because there
> seemed to be a lot of noise centered around implementation/
> maintainability.
>
> There was some noise, but as I believe the patch shows, it was misplaced.
>
> > I'm curious if the actual premise of the syntactic/sugar conversion has
> been discussed/debated yet? i.e. making dynamic/stringly calls look like
> normal calls is very clean, but it's also very misleading (by definition;
> they're not normal/safe/checked calls) with a potential net reduction in
> ergonomics.
>
> In fact, the calls are fully type safe and checked. The JSON example
> shows that.
>
> I think what you’re getting at here is that there is opportunity to misuse
> this feature. It is certainly not something that every one should use
> commonly on their types: it’s a power feature that is extremely important
> for some narrow cases.
>
> I’ll observe that this is exactly the sort of feature that Swift
> traditionally includes, and there are many examples of this: generalized
> operator overloading, the ability to syntax extend almost everything in the
> language (e.g. literals), user defined pattern matching in switches, etc.
>
> > Anyway, there's my primary concern. Has this been addressed yet? Has any
> thought been given to requiring '?'/'!' on these calls (or some other
> symbol, but this would retain some cleanliness..) to opt into the inherent
> fallibility and distinguish them visually?
>
> This feature isn’t unsafe at all, I’m not sure why that would be
> appropriate.
>
> -Chris
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
You're saying that there is universally no inherent difference, and that all calls "determine if you have called it" correctly, but then picked one of only a handful of cases in current practice where that is actually true. Yes "+" (/other math operators) and array access are unsafe, but most other things in Swift are safe by default, and you have to opt into un-safety (e.g. forcing or checking an optional or throwing call) — this is a main tenant of the language. Perhaps I was not totally clear while mixing and matching my observations/interpretations of safety and fallibility in compile vs. runtime and readability vs. writability in my initial email, but I believe the spirit of my concern was clear: there is obviously a difference between dynamic and static languages/calls, and having the syntax the same is misleading in a language centered around static safety, perhaps to a degree where it is ergonomically counter productive. On Mon, Nov 27, 2017 at 4:12 PM, Magnus Ahltorp wrote: > > 27 Nov. 2017 22:38 Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I tuned out the initial discussions of this proposal because there > seemed to be a lot of noise centered around implementation/maintainability. > I'm curious if the actual premise of the syntactic/sugar conversion has > been discussed/debated yet? i.e. making dynamic/stringly calls look like > normal calls is very clean, but it's also very misleading (by definition; > they're not normal/safe/checked calls) with a potential net reduction in > ergonomics. > > There is nothing that is inherently non-fallible with "normal" Swift > calls. As far as the caller can tell, any function or method you call can > fail. There is no difference here; the implementation of the "user-defined > dynamic member lookup" object will determine if you have called it in a > proper way or not, in the same way as "+" will determine if you have called > it in a way that overflows or not. > > /Magnus > > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
I tuned out the initial discussions of this proposal because there seemed to be a lot of noise centered around implementation/maintainability. I'm curious if the actual premise of the syntactic/sugar conversion has been discussed/debated yet? i.e. making dynamic/stringly calls look like normal calls is very clean, but it's also very misleading (by definition; they're not normal/safe/checked calls) with a potential net reduction in ergonomics. Cleanliness is a double edged sword, which Swift already suffers at the hand of. Type inference and overloading are fantastic. Literal convertibles are magic. Omitting "redundant" types/descriptors from signatures is so right. But they (especially when combined) lead to a lot of Swift code ranging from unclear to meaningless at a glance, with a couple option-clicks per line necessary to extract exactly what's going on from the all knowing compiler. This is a hindrance in Xcode, and not possible if you've only got the text (like on GitHub). But whereas these features only really effect code comprehension, the proposed syntactic conversion effects code comprehension and writing safe code. Usually in Swift you have to opt in at the call site to unchecked behaviour, but with these changes, working in a mixed pure Swift/Pythonic Swift environment, if you don't pay a good deal of attention to each object you're writing calls on (whether it conforms to the new protocol), you can write totally unchecked code by accident. Not to say the code comprehension itself isn't a problem — with type inferred/descriptor-cleaned code it's evident the information isn't there, so if something isn't clear there's an impetus to option-click/check it. With this dynamic-posing-as-checked code, the truth and the evidence is disguised. Anyway, there's my primary concern. Has this been addressed yet? Has any thought been given to requiring '?'/'!' on these calls (or some other symbol, but this would retain some cleanliness..) to opt into the inherent fallibility and distinguish them visually? Thanks, Mathew On Mon, Nov 27, 2017 at 6:04 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > I’d like to formally propose the inclusion of user-defined dynamic member > lookup types. > > Here is my latest draft of the proposal: > https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 > https://github.com/apple/swift-evolution/pull/768 > > An implementation of this design is available here: > https://github.com/apple/swift/pull/13076 > > The implementation is straight-forward and (IMO) non-invasive in the > compiler. > > -Chris > > ___ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [discussion] SPI?
It looks like a `hidden` access control has been discussed before: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/031881.html Not directly related, but would serve a similar purpose. I'm fairly sure whether it's revisiting protected, or something like 'hidden' with special imports, or getting to SPI access control, or just getting to better modules/imports ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024666.html), it's not going to happen soon, requiring a ton of debate and design that people aren't even necessarily interested in anymore/at the moment. But regardless, whatever solution(s) are implemented in whatever version of Swift, the least common denominator implication will be that internal symbols will be able to be named independently from visibility concerns (currently I use `_privateButInternalSymbol` and `_int_internalButPublicSymbol` for clarity out/inside of module, which sucks). What if in the meantime, as a measure to allow stdlib and other frameworks to lock in the symbols/SPI they *would* use with full access/visibility control, we change https://github.com/apple/swift/blob/6573a5fe41b63da476278caa7ba7ee9e3c246b25/lib/AST/Decl.cpp#L396 to (remove the `isStdlibModule` check) not just check for underscores, but check for a new `@_hidden` directive? On Tue, Aug 15, 2017 at 12:03 PM, Mathew Huusko V wrote: > Yes, sorry. First and foremost I'm referencing SPI access control as > mentioned in https://github.com/apple/swift/blob/master/docs/ > LibraryEvolution.rst#backdating, https://github.com/apple/ > swift/blob/master/docs/AccessControlInStdlib.rst#public, > https://github.com/apple/swift/blob/master/docs/AccessControl.rst#access- > control, etc. > and "used" in places like https://github.com/apple/ > swift/blob/master/stdlib/public/core/String.swift#L864 > > i.e. some way to say "this symbol is public/visible, but only for relevant > clients, like associated or extension frameworks". The value add for stdlib > is high, as it would be able to lock down a plethora of those > public-but-underscored symbols. Personally I don't need strong access > control as much as just lightly enforced visibility control (Obj-C never > had real access control, everything was accessible dynamically with enough > effort, but fine grained visibility via headers was extremely > valuable/important to API design), but I imagine if this is going to be > tackled at all, bringing it all the way is appropriate. > > In my mind there would be two cases to cover: > 1) Restricting SPI to a known client. `public(client: Foundation)` on a > type or member would only make it accessible to Foundation. > 2) Restricting SPI to clients interested in that SPI space. `public(SPI: > StringImpl)` on a type/member would only make it visible to clients/files > that explicitly `import SomeModule(SPI: StringImpl)` vs. apps casually > importing SomeModule or clients interested in ArrayImpl SPI. > > On Tue, Aug 15, 2017 at 5:24 AM, Félix Cloutier > wrote: > >> Could you clarify? What do you hope to achieve beyond access/visibility >> control? >> >> > Le 14 août 2017 à 07:19, Mathew Huusko V via swift-evolution < >> swift-evolution@swift.org> a écrit : >> > >> > Curious if SPI access/visibility control has been discussed/planned? I >> know the standard access control debate is long past, but this still seams >> rather important, especially for stdlib (and would presumably have ABI >> implications) and other large frameworks. >> > ___ >> > swift-evolution mailing list >> > swift-evolution@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [discussion] SPI?
Yes, sorry. First and foremost I'm referencing SPI access control as mentioned in https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#backdating, https://github.com/apple/swift/blob/master/docs/AccessControlInStdlib.rst#public , https://github.com/apple/swift/blob/master/docs/AccessControl.rst#access-control, etc. and "used" in places like https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L864 i.e. some way to say "this symbol is public/visible, but only for relevant clients, like associated or extension frameworks". The value add for stdlib is high, as it would be able to lock down a plethora of those public-but-underscored symbols. Personally I don't need strong access control as much as just lightly enforced visibility control (Obj-C never had real access control, everything was accessible dynamically with enough effort, but fine grained visibility via headers was extremely valuable/important to API design), but I imagine if this is going to be tackled at all, bringing it all the way is appropriate. In my mind there would be two cases to cover: 1) Restricting SPI to a known client. `public(client: Foundation)` on a type or member would only make it accessible to Foundation. 2) Restricting SPI to clients interested in that SPI space. `public(SPI: StringImpl)` on a type/member would only make it visible to clients/files that explicitly `import SomeModule(SPI: StringImpl)` vs. apps casually importing SomeModule or clients interested in ArrayImpl SPI. On Tue, Aug 15, 2017 at 5:24 AM, Félix Cloutier wrote: > Could you clarify? What do you hope to achieve beyond access/visibility > control? > > > Le 14 août 2017 à 07:19, Mathew Huusko V via swift-evolution < > swift-evolution@swift.org> a écrit : > > > > Curious if SPI access/visibility control has been discussed/planned? I > know the standard access control debate is long past, but this still seams > rather important, especially for stdlib (and would presumably have ABI > implications) and other large frameworks. > > ___ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [discussion] SPI?
Curious if SPI access/visibility control has been discussed/planned? I know the standard access control debate is long past, but this still seams rather important, especially for stdlib (and would presumably have ABI implications) and other large frameworks. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [discussion] What generics feature would this be?
Very interesting. Is this likely to be changed in the future (either
existentials conforming to their protocols, or `S: Protocol` specifically
allowing for existentials)?
Also, is this at all related? Another instance of at naive/face value
something seeming like it should conform, but not..
protocol Special {}
protocol SubSpecial: Special {}
let spec: Special.Protocol = Special.self // works
let subspec: Special.Protocol = SubSpecial.self // doesnt work
On Wed, Aug 9, 2017 at 7:17 PM, Austin Zheng wrote:
> A existential type of some protocol `P`, counterintuitively, doesn't
> conform to itself, unless it's an Objective-C protocol.
>
> Because `S : Special` means S has to be a type that conforms to the
> protocol `Special`, and `special` is of the existential type `Special`, the
> existential type `Special` doesn't conform to the protocol `Special`, so it
> can't be used for `S`.
>
> Best,
> Austin
>
> > On Aug 9, 2017, at 7:19 AM, Mathew Huusko V via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > Curious what part of generics the below would fall under? This hit me by
> surprise/makes even non-generic/Self-depending protocols un-interchangeable
> with classes..
> >
> > ```
> > protocol Special {}
> >
> > func doWithAndReturn(_ special: S) -> S { ... }
> >
> > let special: Special = ...
> >
> > // "error: Generics parameter 'S' could not be inferred"
> > // works fine when 'Special' is a class
> > let newSpecial: Special = doWithAndReturn(special)
> > ```
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [discussion] Class stored properties?
I don't follow. What's a singleton/how? If you mean my example, the whole
point/need for the feature is so it's not. I want `.value` to be unique
storage for each subclass.
On Wed, Aug 9, 2017 at 7:09 PM, Robert Widmann wrote:
> This is a singleton, it just happens to be in class scope.
>
> ~Robert Widmann
>
> > On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Curious if class stored properties have ever been discussed (doesn't
> seem so..)?
> >
> > Also, assuming no, and assuming there's a good reason no/they're not
> coming anytime soon, what are some patterns people have been using in their
> place? I was considering something like..
> >
> > class SomeClass {
> > private static var _classValues = [SomeClass.Type: Int]()
> >
> > class var value: Int {
> > get { _classValues[self] }
> > set { _classValues[self] = newValue }
> > }
> > }
> >
> > .. but then I remembered types aren't hashable yet either (so I guess I
> need to stringify it first).
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [discussion] What generics feature would this be?
Curious what part of generics the below would fall under? This hit me by
surprise/makes even non-generic/Self-depending protocols un-interchangeable
with classes..
```
protocol Special {}
func doWithAndReturn(_ special: S) -> S { ... }
let special: Special = ...
// "error: Generics parameter 'S' could not be inferred"
// works fine when 'Special' is a class
let newSpecial: Special = doWithAndReturn(special)
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [discussion] Class stored properties?
Curious if class stored properties have ever been discussed (doesn't seem
so..)?
Also, assuming no, and assuming there's a good reason no/they're not coming
anytime soon, what are some patterns people have been using in their place?
I was considering something like..
class SomeClass {
private static var _classValues = [SomeClass.Type: Int]()
class var value: Int {
get { _classValues[self] }
set { _classValues[self] = newValue }
}
}
.. but then I remembered types aren't hashable yet either (so I guess I
need to stringify it first).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)
Perfect, thanks! On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor 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 wrote: > >> >> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca < >> retired.hunter.dj...@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 gen
Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)
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 wrote: > > > On Aug 7, 2017, at 11:34 PM, Elviro Rocca < > retired.hunter.dj...@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
Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)
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 wrote: > > > On Aug 4, 2017, at 12:03 PM, Mathew Huusko V 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 > > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)
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 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 > > > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)
Per
https://lists.swift.org/pipermail/swift-evolution-announce/2016-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?
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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
