Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

> On Jan 7, 2017, at 10:02 AM, Adrian Zubarev via swift-evolution > wrote: > > True, but there are a few edge cases where Self simply does not work. > > On classes the return type has the contract to return self. > Even if we get SE–0068, will Self work in generic

Re: [swift-evolution] "with" operator a la O'Caml?

> On Dec 17, 2016, at 8:40 PM, Andy Chou via swift-evolution > wrote: > > I like that structs are value types in Swift, this encourages the use of > immutable data. O'Caml has an operator "with" that allows for copying an > existing struct with a change to one

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

changed inference. > > Jordan > > >> On Mar 23, 2017, at 02:11, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> A further benefit of this scheme is that it makes the behavior of @objc on >> class members consisten

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution > wrote: > > 1) Allow stored properties in same-module extensions. This has been > discussed in the past and is a possibility, but I suspect it is not in scope > for consideration during Swift 4.

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

, Joe Groff via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution >>>> <swift-evolution@swift.org <mailto

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

A further benefit of this scheme is that it makes the behavior of @objc on class members consistent between NSObject-derived and Swift-native classes. Right now, it is legal to apply @objc to a _member_ of a Swift-native class; this is what allows Swift-native classes to model @objc protocols

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution > wrote: > >> >> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution >> wrote: >> >> >>> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >>>

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] > > I'm definitely in favor of this. Apart from the various motivations discussed > in

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > I'm going to have to

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

Here’s an idea for working around the problem of the lack of static knowledge during migration. Probably it’s kind of tacky and won’t get much traction in it’s current form, but it might start some useful discussion at least. Right now, @objc when applied to a _class_ is completely useless; if

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 5:32 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > > On Mar 26, 2017, at 7:03 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 11:12 AM, Karl Wagner via swift-evolution > wrote: > > I’d like to pitch the following two language changes. Both of them are > technically possible today if you manually write thunks for the relevant > protocol requirements, but it would be

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 28, 2017, at 12:10 AM, Adrian Zubarev > wrote: > > It’s probably the influence from iOS development where I have delegate > protocols like this one: > > @objc public protocol _ContainerViewControllerDelegate: class { > > @objc optional func

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 27, 2017, at 1:48 PM, Adrian Zubarev via swift-evolution > wrote: > > Assuming we’ll get that functionality, both var and let should satisfy the > protocol requirements right? > In theory, there’s no reason not to allow that. > If it is valid, could we

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution > wrote: > > This introduces a source-breaking change that affects consumers of APIs that > are explicitly taking or vending instances of bridged CF or Objective-C > types. However, recent importer

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution > wrote: > > Alternatives considered > > Do nothing and continue to accept this implicit conversion. One alternative would be to import CFArray as a typealias for NSArray, etc, erasing the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

How about private(world), public(module), internal(file)? :-) Slava > On Mar 25, 2017, at 4:15 PM, Adrian Zubarev via swift-evolution > wrote: > > Please do not start a debate about `private(module)` which is equavalent to > `internal`, otherwise you could equally

Re: [swift-evolution] Code blocks and trailing closures

> On Mar 15, 2017, at 3:35 AM, Rien via swift-evolution > wrote: > > What does the following code fragment do? > > serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return } > > The only possible answer is: I don’t know. No, that is incorrect.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution > wrote: > > -1 on this as well for similar reasons. Places where I use fileprivate (aside > from what was automatically migrated by Xcode) can be counted on fingers of > one or two hands. > > I

Re: [swift-evolution] where clauses on enum cases

You’re asking for GADTs: https://en.wikipedia.org/wiki/Generalized_algebraic_data_type This feature is difficult to implement correctly and efficiently and I doubt Swift will ever support it, but you never know… Slava > On Mar

Re: [swift-evolution] Swift's reflection

Adding write reflection to the existing Mirrors implementation should not be too difficult and we would accept a well-written PR that adds this capability. Slava > On Mar 15, 2017, at 8:10 AM, Dimitri Racordon via swift-evolution > wrote: > > Hello fellow

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Itai, I’m wondering what the motivation is for keeping this as part of Foundation and not the standard library. It seems like you’re landing an implementation of this in the Foundation overlay on master, and another copy of all the code will have to go into swift-corelibs-foundation. This

Re: [swift-evolution] Infer types of default function parameters

-1. We already have a related feature for stored properties in structs and classes, and it causes a performance problem when compiling multi-file modules in non-WMO mode. Suppose you have: — a.swift — struct Box { var x = } — b.swift — func takesABox(_: Box) {} — c.swift — func

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 16, 2017, at 4:00 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Mar 16, 2017, at 5:54 PM, Ben Rimmington wrote: >> >> On 16 Mar 2017, at 21:14, Matthew Johnson wrote: On Mar

Re: [swift-evolution] Revisiting 'T != Type' in where clause

Overload resolution has a lot of heuristics, but it’s not magic. It simply doesn’t know how to handle this case. I’d be in favor of consolidating and simplifying the overload resolution rules, with the goal of disambiguating common cases that are currently ambiguous. We might even be able to

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:32 PM, Robert Bennett wrote: > > Agreed, I'm fine with a way of achieving this without T != Type. I suppose I > should have made the subject "Fix Swift's type checker in this particular > case". > > I still have trouble figuring out *how* it can

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:36 PM, Jaden Geller wrote: > > >> On Mar 16, 2017, at 8:27 PM, Slava Pestov wrote: >> >> Overload resolution has a lot of heuristics, but it’s not magic. It simply >> doesn’t know how to handle this case. >> >> I’d be in

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 9, 2017, at 3:01 PM, Jon Shier via swift-evolution > wrote: > > I generally dislike any language change desired because it makes the > compiler implementation easier. We saw a few such changes for Swift 3 and all > of them were net negatives for the

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

> On Mar 8, 2017, at 11:33 PM, Adrian Zubarev via swift-evolution > wrote: > > I forget to mention, this should be also valid: > > let `42` = 42 > > print(`42`) > > struct A { > let `0` = 0 > } > > let number = A().0 > -1 This seems really confusing.

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

> On Mar 8, 2017, at 11:46 PM, Adrian Zubarev > wrote: > > I don’t have more precise examples except something like TCP socket error > codes as an enum. > I would expect that the error code is available as a computed property of the enum value, perhaps as

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

> On Mar 2, 2017, at 3:24 AM, Anton Zhilin via swift-evolution > wrote: > > I think that tuples should remain what they are now. Static-length vectors > should be types on their own and interact with tuples, with structs and with > Array<…> in the same way. > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Strong -1. This is a source breaking change, but Swift 4 stage 2 is already over. Slava > On Apr 6, 2017, at 4:10 PM, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0169 "Improve Interaction Between private Declarations and > Extensions" begins now

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 2, 2017, at 10:48 PM, David Hart wrote: > > Somewhat related: I have a similar problem in a project where I need two > different Codable conformances for a type: one for coding/decoding from/to > JSON, and another one for coding/decoding from/to a database row. The

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Oh right. @_specialize modifies the original entry point to do runtime dispatch among the possible specializations. So the overhead comes from the unnecessary checks. I guess ideally we would have two versions of @_specialize, one adds the runtime dispatch whereas the other one just publishes

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 11:04 PM, Taylor Swift wrote: > > > > On Oct 5, 2017, at 12:52 AM, Slava Pestov > wrote: > >> >> >>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >>>

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution > wrote: > > i’m just tryna follow along here && this is probably a dumb question, but is > it possible for a generic function to be emitted as a set of specialized > functions into the client, but not

[swift-evolution] Pitch: Cross-module inlining and specialization

Hi all, Here is a draft proposal that makes public a feature we’ve had for a while. Let me know what you think! Cross-module inlining and specialization ("@inlinable") Proposal: SE- Authors: Slava Pestov , Jordan Rose Review

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for taking a look! > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky > wrote: > > I am hugely in favor of an @inlinable attribute, and I look forward to its > arrival with relish! > > Some feedback: > > 1. I think “inlinable” is the right

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 2:20 PM, Greg Parker <gpar...@apple.com> wrote: > > >> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> inlinable declarations

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

il.com> wrote: > > Very much looking forward to this. Any possibility of rolling in some version > (ha) of @_versioned so that @inlinable functions can reference internal > declarations? > > > On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution > <swi

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:17 PM, Chris Lattner wrote: > >> >> On Oct 3, 2017, at 10:15 PM, Slava Pestov wrote: >> >> >> >>> On Oct 3, 2017, at 10:14 PM, Chris Lattner wrote: >>> >>> On Oct 2, 2017, at 11:11 PM, Slava Pestov

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:32 PM, Jonas B wrote: > > >> On 4 Oct 2017, at 13:36, Slava Pestov > > wrote: >> >>> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution >>>

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 11:05 PM, Jonas B wrote: > > >> On 4 Oct 2017, at 14:33, Slava Pestov > > wrote: >> >> @_versioned makes a symbol visible externally without making it visible from >> the language. There is no requirement

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:21 PM, Jonas B wrote: > > >> >> Yeah, but the compiler could handle NSObject as a special case. Are there >> enough other special cases that it is worth documenting and exposing a >> fragile attribute on classes to the user? >> > > Pitching in

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 9:15 PM, Xiaodi Wu wrote: > > > On Mon, Oct 2, 2017 at 22:23 Slava Pestov > wrote: >> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu > > wrote: >> >> On Mon, Oct

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for the review! > On Oct 2, 2017, at 10:57 PM, Chris Lattner <clatt...@nondot.org> wrote: > > This is a great proposal, I’m a strong supporter, but have one question and > one strong push back: > >> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evo

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

It would be a trivial change to allow @_versioned on private and fileprivate declarations, but there are two pitfalls to keep in mind: - Private symbols are mangled with a ‘discriminator’ which is basically a hash of the file name. So now it would be part of the ABI, which seems fragile — you

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov > wrote: > >> On Oct 2, 2017, at 7:52 PM, Kelvin Ma > > wrote: >> >> Is

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: > > Is this only a problem with fileprivate or does it extend to private members > too? I feel like this would be a very valuable feature to support. Private members too. Consider this example, struct S { private func f()

Re: [swift-evolution] Property Getter Return Statement

> On Oct 10, 2017, at 1:00 PM, Slava Pestov <spes...@apple.com> wrote: > >> >> On Oct 9, 2017, at 10:54 AM, Jordan Rose <jordan_r...@apple.com> wrote: >> >> >> >>> On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution >>&g

Re: [swift-evolution] Property Getter Return Statement

> On Oct 9, 2017, at 10:54 AM, Jordan Rose <jordan_r...@apple.com> wrote: > > > >> On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >>> On Oct 7, 2017, at 7:07 AM, Jam

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution > wrote: > > I don’t see how it’s impractical. Quite a lot about how the library should be > optimally compiled and used depends on what you plan to do with it. If it’s > going to be installed somewhere

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 10:57 PM, Chris Lattner wrote: > > 1) Why not another level of access control? There is a reasonable argument > that what you’re doing is making something “more public than public” or that > you’re making the “body also public”. I’m not strongly in

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > >> This semantic doesn’t make sense to me, and I think we need to change it. I >> think we are better served with the semantics of “the body may be in

Re: [swift-evolution] Property Getter Return Statement

> On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution > wrote: > > Is it widely agreed that it is necessary to require a return statement on a > one line property getter? > > var session: AVCaptureSession { get { return layer.session } } > > Or could

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 1:17 PM, Michael Ilseman via swift-evolution > wrote: > > Another benefit of the always-emit-into-client-and-omit-from-libary-binary is > cross-call consistency. A function foo could change in a way such that *all* > calls using either the new

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution > wrote: > > > Now I understand that this use-case is deferred for a later separate > discussion, but my point here is that the name and the semantics of this > attribute should be somewhat

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > >> >> On Oct 3, 2017, at 9:50 AM, Joe Groff > > wrote: >> >> >> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:09 PM, Chris Lattner wrote: > > On Oct 3, 2017, at 9:59 PM, Slava Pestov > wrote: It wouldn't avoid the complexity, because we want the "non-ABI, always-emit-into-client" behavior for the

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:14 PM, Chris Lattner wrote: > > On Oct 2, 2017, at 11:11 PM, Slava Pestov wrote: >>> In any case, even if you’re opposed to these approaches, I’d love for the >>> “alternatives considered” section to indicate what the objection

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Hi all, Summarizing the thread so far, I see there were three main points of discussion: - The name itself, @inlinable, is causing some confusion. Chris suggested a more general name, like @fragile. A few other possible names were discussed. I don’t think we’ve decided on the best name yet so

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

> On Nov 12, 2017, at 7:27 PM, Nevin Brackett-Rozinsky > wrote: > > On Sun, Nov 12, 2017 at 10:16 PM, Slava Pestov > wrote: >> Pardon my lack of imagination, but could you provide an example of a call >> site

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

> On Nov 12, 2017, at 7:14 PM, Nevin Brackett-Rozinsky > wrote: > > On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov > wrote: > Yeah, this is an unfortunate wart. Right now unqualified lookup starts at the >

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

Yeah, this is an unfortunate wart. Right now unqualified lookup starts at the innermost scope and stops when it finds a candidate which matches the name being looked up. Overload sets are only formed if there are multiple candidates inside the same scope, not in different scopes. It would be

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution > wrote: > > 2. Allow closures when assigned to a function type to be: > 2a. Recursive. Local functions can also be mutually recursive: func f() { func foo() { bar() } func bar() { foo()

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 27, 2017, at 11:04 AM, Ben Langmuir wrote: > > > >> On Nov 17, 2017, at 5:59 PM, Slava Pestov > > wrote: >> >> >> >>> On Nov 17, 2017, at 8:57 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 8:44 AM, Matthew Johnson wrote: > > func makeResource( > with configuration: Configuration = () where Configuration == Void, > actionHandler: @escaping (Action) -> Void = { _ in } where Action == Never > ) Similar question to the one I

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 1:35 PM, Matthew Johnson wrote: > >>> * the compiler doesn’t have to reason about an overload set which might >>> improve build times, etc >> >> They’re effectively equivalent, because we still have to decide which subset >> of the default

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 27, 2017, at 3:38 PM, Matthew Johnson via swift-evolution > wrote: > > You are effectively proposing that in this very narrow case we perform > overload resolution on a symbol in a generic type context *after* the generic > type has been replaced with a

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

Hi Tony, So if my understanding is correct, the basic proposal is the following: func id(t: T ?= T.defaultValue) { return t } extension Int { static var defaultValue = 0 } extension String { static var defaultValue = “” } id() as Int // returns 0 id() as String // returns “” id() as

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 30, 2017, at 10:23 PM, Chris Lattner via swift-evolution > wrote: > > The difference between it and AnyObject lookup is that AnyObject lookup is: > > b) type unsafe Can you explain in what sense AnyObject lookup is type unsafe where your proposal is type

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution > wrote: > > So I guess I’m saying, I want more thought put on the topic of whether enums > defined in Swift should actually default to non-exhaustive, and I’m now > leaning towards the idea that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

They would not be boxed, but there would be additional indirection required at runtime, using the same mechanism currently used for unspecialized generics. Slava > On Dec 19, 2017, at 6:42 PM, Kevin Ballard wrote: > > Isn’t this going to turn both structs and non-C-like enums

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 17, 2017, at 8:57 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Nov 17, 2017, at 15:20, Ben Langmuir > > wrote: >> >> Hi Jordan, >> >> First off, this is clearly the model we should have had

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 1:39 PM, Chris Lattner via swift-evolution > wrote: > > It is straight-forward (and fits very very naturally into the Swift call > model) to support the second one as an atomic thing, which is I think what > you’re getting at. What if you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 20, 2017, at 1:58 PM, Drew Crawford via swift-evolution > wrote: > > I'm "weak oppose" on this proposal. > > The core premise here is to increase the encapsulation of a struct around its > member variables. But I think the purview of encapsulation is

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Ignoring synthesized conformances for a second, think about how you would manually implement a conformance of a tuple type to a protocol. You would need some way to statically “iterate” over all the component types of the tuple — in fact this is the same as having variadic generics. If we had

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 20, 2017, at 11:14 PM, Drew Crawford wrote: > > It would improve the important clients without harming other clients to use > the following implementation for our type: if the sorted accessor is used > before the unsorted one, sort the underlying storage,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 6:02 PM, David Hart wrote: > > Can somebody explain to me what are > nominal and structural types and why Optional should really be a structural > type? Nominal types are structs, enums, protocols and classes. They have declarations in source and

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 16, 2017, at 2:56 PM, Tino Heth via swift-evolution > wrote: > > >> the stat suggests that in 90%+ real-life cases [weak self] is used so the >> "weak func" syntax sugar is worth to consider as an addition to this >> proposal. > Slightly OT: > Just

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 16, 2017, at 3:07 PM, Howard Lovatt via swift-evolution > wrote: > > Where I am proposing a change is that if a closure with generic arguments is > encountered it is transformed into the equivalent struct and the struct is > typed as it currently is (or

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 16, 2017, at 4:38 PM, Howard Lovatt wrote: > > When the user writes: > > let increment: (T) throws -> T where T: Numeric = { $0 + 1 } > increment(1) // 2 > increment(1.1) // 2.1 This means that ‘increment’ is a *value* with a generic function

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Hi Chris, > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > Hello all, > > I have a couple of proposals cooking in a quest to make Swift interoperate > with dynamically typed languages like Python better. Instead of baking in > hard

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 6:01 PM, Chris Lattner wrote: > > It is. It is strictly sugar, as mentioned in the proposal. All new code has a cost. > I do not expect any SIL or IRGen changes associated with this proposal, just > type checker changes. The type checker changes

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution > wrote: > > Setting this aside, I’m very curious to hear whether type providers influence > your thinking after you’ve had a chance to look into them. I have always > thought they were very cool.

Re: [swift-evolution] Abstract methods

t;> wrote: > >> >> >>> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi <pana...@gmail.com >>> <mailto:pana...@gmail.com>> wrote: >>> >>> >>> >>> Sent from my iPhone >>> >>>> On 4 Nov 2017,

[swift-evolution] Pitch: Remove default initialization of optional bindings

Hi all, Right now, the following two declarations are equivalent: struct S { var x: Int? } struct S { var x: Int? = nil } That is, mutable bindings of sugared optional type (but not Optional!) always have a default value of ‘nil’. This feature increases the surface area of the language

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

likely impact everyone using mutable optionals. If you really want to >> find out, perhaps run it agains the compatibility suite? >> >> >> Jon >> >>> On Nov 6, 2017, at 5:33 PM, Slava Pestov via swift-evolution >>> <swift-evolution@swift

Re: [swift-evolution] Abstract methods

Abstract methods and classes seem like they will introduce a fair amount of complexity in the type checker, particularly around metatypes and constructors, because now we have this new concept of a class that cannot be directly instantiated. I’m not sure the cost is worth the benefit. Slava >

Re: [swift-evolution] Extending trailing closure sugar similar to property accessors

> On Nov 2, 2017, at 4:04 PM, Eric Summers via swift-evolution > wrote: > > // A sugar similar to property accessors for multiple trailing closures: > foobar(a: 1, b: 2) { > completionBlock { x, y in > // ... > } > failureBlock { i, j in > // ...

Re: [swift-evolution] Extending trailing closure sugar similar to property accessors

> On Nov 2, 2017, at 5:58 PM, Eric Summers wrote: > > A similar problem exists with property accessors. Although you could call > those keywords, they will probably be extensible when behaviors are > introduced leading to a similar situation. It can be worked

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

e, say, AnyObject dispatch :) ) Slava > > On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Hi all, > > Right now, the following two declarations are equivalent: > > st

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Same here, but I wouldn’t care much if it were gone. > > > Am 7. November 2017 um 21:40:56, David Hart via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution > wrote: > > That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap. > > Chris has mentioned in interviews that such a system is "a big feature that’s > open-ended and requires a

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 3, 2017, at 9:16 PM, Swift via swift-evolution > wrote: > > It’s possible I missed something, but my attempt at implementing it only > touched 3 files. One was the actual implementation, another was adapting the > diagnostics messages, and the third was

Re: [swift-evolution] Abstract methods

> On Nov 2, 2017, at 8:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution >> > wrote: >> >> Swift architectures use much less

Re: [swift-evolution] Abstract methods

> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi <pana...@gmail.com> wrote: > > > > Sent from my iPhone > >> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Protocols define requir

Re: [swift-evolution] Optional Argument Chaining

> On Dec 11, 2017, at 2:41 PM, Jared Khan via swift-evolution > wrote: > > I missed the previous threads! I’ve found one of the relevant threads here: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024201.html > >

<    1   2   3   >