Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

SGTM! -Chris > On Jan 17, 2018, at 3:14 PM, Connor Wakamo wrote: > > > >> On Jan 12, 2018, at 11:02 PM, Chris Lattner > > wrote: >> >>> On Jan 12, 2018, at 6:22 PM, Connor Wakamo >>

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 17, 2018, at 4:19 PM, Jordan Rose wrote: >>> >>> The parser has fairly general support for declmodifiers, and my proposal >>> fits directly into that. The only extension is that ‘default’ isn’t a >>> decl, and I don’t think we have a statement modifier yet.

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 16, 2018, at 10:24 AM, Jordan Rose wrote: >>> On Jan 12, 2018, at 3:08 PM, Jordan Rose >> > wrote: >>> >>> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's >>> point very

Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

On Jan 15, 2018, at 11:01 PM, Xiaodi Wu via swift-evolution wrote: > - Can we change the semantics? Maybe, but I doubt ExpressibleByFloatLiteral > can be outright replaced. You're not the first to wonder about how to design > an alternative protocol. Dig through the

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

. This is perfectly well defined and just falls out of the model. That said, I agree that the issue of source dependencies that might use this is a significant problem. IMO, that argues strongly for “unknown default:” producing a warning. -Chris > On Jan 12, 2018, at 10:49 PM, Chris Lattner via sw

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Why is that a problem? Despite referring to it as the “unstable” half, if we just put deprecated stuff in it, it would still be stable and should work for that. You are right that things would be more complicated if it is used as a “staging ground” for features that eventually make it into

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

On Jan 12, 2018, at 4:43 PM, Ted Kremenek wrote: > Hi Chris, > > Instead of responding to each of your point bit-by-bit, I’ll try a different > tactic to explain my reasoning — which may be wrong — by explaining how I see > things top down with the tradeoffs they incur.

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 12, 2018, at 6:22 PM, Connor Wakamo wrote: > >>> The second case, and the one I’m more worried about, is subclassing. If, >>> for instance, you have the following: >>> >>> class FooView: UIView, CustomPlaygroundRepresentable { >>> var

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 3:08 PM, Jordan Rose wrote: > > Okay, I went back to `unknown case` in the proposal, but mentioned Chris's > point very specifically: if the compiler emits an error, we should go with > `case #unknown` instead. (I'm very strongly in the "warning"

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

On Jan 11, 2018, at 11:22 AM, Connor Wakamo wrote: >>> I don’t think we can change this to return `Any` instead of `Any?`. I think >>> there are potentially cases where a developer might want to selectively >>> opt-in to this behavior. >> >> Which cases? How important are

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution > wrote: > > A question about the new #unknown behavior. Is it intended to be used for > error handling too ? > Will it be possible to use in catch clause ? If we go with the #unknown approach, then

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> On Jan 11, 2018, at 9:26 PM, Gwendal Roué via swift-evolution > wrote: > > Hello, > >> Le 12 janv. 2018 à 02:36, Paul Cantrell via swift-evolution >> a écrit : >> >> The question I was weighing on it — what I thought Chris and Brent

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 11, 2018, at 12:22 AM, Ted Kremenek <kreme...@apple.com> wrote: > > > >> On Jan 9, 2018, at 11:48 AM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> IMO

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 11, 2018, at 12:01 AM, Ted Kremenek wrote: >> The nice thing about this is that only people who use these things would >> have to pay the cost, and you can directly message this by deprecating all >> the stuff in it. Think about it as an overlay for the Swift

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 10, 2018, at 10:10 AM, Jordan Rose wrote: > >>> >>> - Matching known cases is a feature, not a limitation, to avoid existing >>> code changing meaning when you recompile. I'll admit that's not the >>> strongest motivation, though, since other things can change

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

Brent, thanks for the detailed response, one question about it: > On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution > wrote: > > But that's beside the point. What I think the "`allValues` should be allowed > to be infinite" suggestion misses is

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

is. It shouldn’t be too complicated to add a second implicit > import and only code that is actually using this stuff will have increased > code size. > > > On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evoluti

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 10, 2018, at 2:10 PM, Connor Wakamo wrote: >> What is the use-case for a type conforming to this protocol but returning >> nil? If there is a use case for that, why not have such an implementation >> return “self” instead? > > Riley and Saagar answered this

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 10, 2018, at 10:10 AM, Riley Testut <rileytes...@gmail.com> wrote: > > On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> What is the use-case for a type co

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 9, 2018, at 11:30 PM, Saagar Jha wrote: >> >> In short, can we change playgroundRepresentation to return Any instead of >> Any?. Among other things, doing so could ease the case of playground >> formatting Optional itself, which should presumably get a

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 10, 2018, at 1:52 AM, Ian Partridge <i...@poncho.org.uk> wrote: > > On 10 January 2018 at 06:29, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: >> Ok, I understand that (among all the other things going on that are clearly

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution wrote: > My objection to the "ValueEnumerable" design--especially in its generalized > form here (versus "CaseEnumerable")--is that the protocol's semantics (and, > we'll recall, protocols in Swift must offer

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Disclaimer: I’m reordering your comments below to suit my nefarious purposes: :-) On Jan 9, 2018, at 3:48 PM, Ben Cohen wrote: >> More to the point though, this seems like an implementation detail of >> Mirrors. What is the plan for Mirrors + ABI stability? >> > >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Jan 9, 2018, at 4:46 PM, Jordan Rose wrote: > Thanks for writing this up, Chris! I addressed the idea of making this an > arbitrary pattern in the revised proposal >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez wrote: > Hi Chris, > > This is great. Thanks for spending time on this! I am in favor of `case > #unknown` to only match unknown cases. > > 1) Would #uknown be available to RawRepresentable structs? I haven’t considered

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Jan 9, 2018, at 12:27 PM, Vladimir.S wrote: >> 2) Swift also has other facilities for pattern matching, including ‘if >> case’. Making switch inconsistent with them is not great. >> 3) As pitched, “unknown case” will match *known* cases too, which is (in my >> opinion :-)

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution wrote: > Good afternoon, Hi Connor, Huge +1 for this proposal, I’m thrilled you’re cleaning this up. Couple of detail questions: > >

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 10:23 AM, Ben Cohen wrote: >>> >>> The old name can live on indefinitely via a typealias (which has no ABI >>> consequences, so could be retired at a later date once everyone has had >>> plenty of time to address the deprecation warnings). Removing it

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 8:16 AM, Zach Waldowski via swift-evolution > wrote: > > I'm not sure a valid use case by a third party makes it hold its weight for > inclusion in the stdlib. Reproducing its feature set is extremely trivial, > and would probably allow you to

Re: [swift-evolution] DynamicMemberLookup proposal: status update

Yes indeed! He and I have been exchanging emails :-) -Chris > On Jan 5, 2018, at 5:20 AM, Ben Rimmington wrote: > > Have you seen John Holdsworth's experiments? > > > -- Ben > >> On 4 Jan 2018, at 20:52, Chris Lattner

[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

The mega-thread about SE-0192 is a bit large, and I’d like to talk about one specific point. In the review conversation, there has been significant objection to the idea of requiring a ‘default’ for switches over enums that are non-exhaustive. This whole discussion is happening because the

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution > wrote: > There exists in the standard library a type `DictionaryLiteral` that deserves > naming re-consideration before we declare ABI Stability, because it’s > confusingly misnamed, being neither a

Re: [swift-evolution] DynamicMemberLookup proposal: status update

On Jan 4, 2018, at 3:43 PM, Nevin Brackett-Rozinsky wrote: > > There’s a lot of information here and it’ll take some time to process it all. > My initial reaction is that a “strong type-alias” feature might help. If one > could write (strawman syntax): > >

[swift-evolution] DynamicMemberLookup proposal: status update

Hi everyone, With the holidays and many other things behind us, the core team had a chance to talk about python interop + the dynamic member lookup proposal recently. Here’s where things stand: we specifically discussed whether a counter-proposal of using “automatically generated wrappers” or

Re: [swift-evolution] [arc optimization] Why doesn't enum destructuring use guaranteed references?

This is a great question, I’m not sure what the answer is: maybe it is a simple case missed by the arc optimizer? -Chris > On Dec 27, 2017, at 9:19 PM, Félix Cloutier via swift-evolution > wrote: > > Running this on my MBP with 10 as the parameter: >

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

> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution > wrote: > > I agree that we need a solution to the problem described. I also agree that > non-exhaustive is most in keeping with the overall design of Swift at module > boundaries. However, I

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution wrote: > Sorry for the delay. I've just updated the proposal text to incorporate > various changes, some contributed by others. > >

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 23, 2017, at 2:59 PM, Chris Lattner wrote: > >>> >>> I'm quite sure that the reason you inverted your "abiPublic" example is >>> because of the same issue. Intuitively, you would want to mark something as >>> "available" in version N and then maybe some special

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Dec 22, 2017, at 9:12 PM, Slava Pestov wrote: >> Deployment platform makes more sense, but I still can't envision a real use >> case. What sorts of `bar()` would hypothetically be necessary for iOS 15 but >> not 16? Why would a third-party library need to increase its

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 9:08 PM, Slava Pestov wrote: > > > >> On Dec 22, 2017, at 9:55 AM, Chris Lattner wrote: > >> When and if we add private cases to enums, we’ll need to be able to >> associate an availability range with an “exhaustive” marker.

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu wrote: > >> In short, respectfully request that you at least add this approach to the >> "alternatives considered” section. > > So, does anyone have any strong objections to Chris’s proposal? > > From an implementation standpoint,

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 11:08 PM, Slava Pestov wrote: >> I am hugely supportive of the features that these attributes enable, but I >> think that the spelling of this is absolutely wrong, and I’m disappointed >> that the extensive discussion we’ve had for months about this

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

To answer your meta question, no, we don’t want to add lots of operators. We are willing to add them if they are very strongly motivated, but prefer not to if there are other ways to solve the problem. In this case it sounds like: x = optionalValue ?? x Is a reasonable substitute. -Chris

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

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018.The proposal is available here: > >

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 20, 2017, at 4:19 PM, Ted Kremenek wrote: > > The review of "SE-0193 - Cross-module inlining and specialization" begins now > and runs through January 5, 2018. > > The proposal is available here: > >

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

> On Dec 20, 2017, at 2:12 PM, Ethan Diamond wrote: > > Would that synthesize an isY() even though .Y has an associated value there? I’m not aware of a concrete design for this idea. The details would definitely need to be figured out, but I don’t see why a double

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

> On Dec 20, 2017, at 1:36 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Dec 19, 2017, at 11:26 PM, Douglas Gregor <dgre...@apple.com> wrote: >> >>> Beyond that, they are small extensions with low complexity, scale

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

> On Dec 19, 2017, at 11:26 PM, Douglas Gregor wrote: > >> Beyond that, they are small extensions with low complexity, scale to >> supporting many different dynamic languages over time, require a level of >> engineering effort that is plausible to be built, and do not

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

In the past, we’ve discussed synthesizing predicate members onto enums. E.g. given: enum E { case X case Y(Int) } you’d get something like: extension E { func isX() -> Bool { return self == .X } func getY() -> Int? { … } } which would solve the client side of this nicely. -Chris

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

> On Dec 12, 2017, at 9:26 AM, C. Keith Ray wrote: > > in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 > > > there is this statement: > > "For this reason, the compiler only permits

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

On Dec 10, 2017, at 10:04 AM, Paul Cantrell wrote: >> This is looking less like a protocol by the day. The square-peg grooves in >> the round hole are getting deeper and more splintery with every revision. > > The flavor of DynamicMemberLookupProtocol with an explicit member

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

On Dec 10, 2017, at 12:22 PM, Xiaodi Wu via swift-evolution wrote: > The last time I said this, I pointed out that this was a protocol which: > > 1. Has no formal members, > 2. But imposes informal requirements enforced by the compiler, > 3. Permits and uses arbitrary

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

> On Dec 10, 2017, at 6:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> On Sat, Dec 9, 2017 at 11:20 Steven

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

> On Dec 7, 2017, at 2:07 PM, Paul Cantrell via swift-evolution > wrote: > > >> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam wrote: >> >>> My main objection to the critical responses is that most of the objections >>> are fundamentally

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

> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam wrote: > fatalError shouldn’t be used excessively. API surface areas for these types are going to be massive (infinite technically). I assume many people are going to be writing a lot of code would these

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

> On Dec 7, 2017, at 9:20 AM, BJ Homer via swift-evolution > wrote: > >> So while it’s theoretically possible to do this, I don’t think it’s a >> concern in practice. The incentives are already in place to encourage doing >> the “right” thing in this case, even

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

> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution > wrote: > > > >> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote: >> >> >> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution >>

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

On Dec 6, 2017, at 8:11 PM, Joe DeCapo via swift-evolution wrote: >> Has all of this ruined the language thus far? No. Because the Swift core >> team doesn’t design, and the Swift community doesn’t adopt, ill-designed >> APIs that turn these facts into problems. > >

Re: [swift-evolution] Core Team vs Random number API discussion

d. I’d hate to leave a group of coders out in the dark (no matter how > small that group may be). > > > On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > Hi All, &

[swift-evolution] Core Team vs Random number API discussion

Hi All, FYI, the Core Team had a brief discussion about the direction of the random number API design being discussed. The strong opinion of the core team is that such an API should *not* be designed with an attempt to service people writing crypto code. Such clients will have requirements

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

On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution wrote: > Alas while Swift's generics provide a nice basic foundation, they still have > big gaps in what can be expressed through them. > And i'm not talking about HKT or any such more advanced use of

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

hods which fall down to this protocol. > > Thanks, > Jon > > > >> On Dec 4, 2017, at 7:30 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution >&g

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

On Dec 5, 2017, at 11:13 AM, Thorsten Seitz wrote: >> This example shows what many on this list don't believe: that any Swift >> method or member access can fail. If the return value of this "get" method >> is an IUO, or not an Optional at all, and doesn't throw, then the

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

> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution > wrote: >> The first one, has no static type info, no compile time checking, it's not >> self documenting, no type inference so people will be forced to use a >> dynamic reference at the call site to store

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

> On Dec 4, 2017, at 12:12 PM, Vladimir.S via swift-evolution > wrote: > > Probably the correct way to have dynamic calls in Swift is to 'mark' such > code with special flag and we need to find it. For example: > > > // Python:d = np.array([1, 2, 3],

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

On Dec 4, 2017, at 10:47 AM, Eagle Offshore via swift-evolution wrote: > Hi Magnus, > > You raise an excellent point. > > The swift journey has been interesting to watch, for sure. I do not believe > anyone has ever started with a rigidly typed system and then

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

> On Dec 4, 2017, at 10:28 AM, Tino Heth <2...@gmx.de> wrote: > > >> The strongest your argument can be is “someone could use dynamic member >> lookup in their API to produce an API with a footgun that hurts their >> users”. I submit for your consideration that there are lots and lots of >>

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

that > approach work with Python? Or if it would, why would we favor this dynamic > member lookup over importing a Python API via a module? > > Dave > >> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >

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

> On Dec 4, 2017, at 1:42 AM, Vincent Esche via swift-evolution > wrote: > > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages).

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

On Dec 3, 2017, at 3:47 PM, Jonathan Hull wrote: >> That’s a good principle. However, a dynamic member lookup is just a member >> lookup. By that principle, it should look like a member lookup :-) > > The behavior is different though (the invisible guard rails which we

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

> On Dec 3, 2017, at 3:39 PM, Matthew Johnson wrote: > >>> If that's the concern, then it would be pretty straightforward to restrict >>> dynamic protocols for stdlib internal use only and expose only PyVal. The >>> trade-off is that all such bridging code would have

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

> On Dec 3, 2017, at 3:34 PM, Matthew Johnson wrote: > >> >> On Dec 3, 2017, at 5:14 PM, Chris Lattner > > wrote: >> >> >>> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu >>

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

> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu wrote: > >> >> and you don’t realize that PyVal’s are involved. However, if you are >> actively writing the code, you have access to code completion and other >> things that tell you these types, and if it is important for the

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

On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <m...@kth.se> wrote: > >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> That’s a good principle. However, a dynamic member lookup is just a member >> lo

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

> On Dec 3, 2017, at 10:54 AM, Thorsten Seitz wrote: > >> >> At that point, there would be a general uproar because IUOs have high >> potential for abuse: Swift is “all about” strong types and safety, which >> IUOs undermine. Strong optionals are considered a pain to

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

On Dec 3, 2017, at 5:45 AM, Jonathan Hull wrote: > Hi Chris, > > I am definitely in favor of providing dynamic features in Swift, and of being > able to interoperate easily with dynamic languages. I really like the idea > overall. Great! > > I was about to write up a

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

On Dec 2, 2017, at 7:11 PM, Matthew Johnson wrote: >> >> This does not improve clarity of code, it merely serves to obfuscate logic. >> It is immediately apparent from the APIs being used, the API style, and the >> static types (in Xcode or through static declarations)

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 2, 2017, at 7:58 PM, Jose Cheyo Jimenez wrote: > > Hi Chis, > > Thank you for pushing this forward. > > My only comment is that on the declaration side it would be great to also > have an attribute to communicate that compiler magic is happening. > >

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution > wrote: > > My point is that our entire design process has been geared towards a > reasonable, best-effort general-use API: It is being designed by community > members who are not specialized in this

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

On Dec 2, 2017, at 2:13 PM, Matthew Johnson wrote: >> For all those reasons, we really do need something like AnyObject dispatch >> if we care about working with dynamically typed languages. The design I’m >> suggesting carefully cordons this off into its own struct

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

On Dec 1, 2017, at 5:50 PM, Matthew Johnson wrote: >>> This design introduces a significant hole in the type system which is >>> contrary to the spirit of Swift. >> >> There is no “hole” in the type system. The proposal is fully type safe. >> >> Further, the addition

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

HI Doug, Your approach can definitely work, but before responding with a tradeoff analysis, I’d like to make sure that I understand what you’re suggesting specifically. > On Dec 1, 2017, at 10:39 AM, Douglas Gregor wrote: >> It also doesn’t provide the great tooling

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

On Dec 1, 2017, at 12:26 AM, Douglas Gregor wrote: >> On Nov 30, 2017, at 10:05 PM, Chris Lattner > > wrote: >> Hi Doug, >> >> Thank you for the detailed email. I have been traveling today, so I haven’t >> had a chance to

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

> On Dec 1, 2017, at 12:26 AM, Douglas Gregor wrote: >>> Philosophy >>> Swift is, unabashedly, a strong statically-typed language. >> >> That’s factually incorrect. > > You’re going to have to explain that statement without reference to AnyObject > (we’ll discuss that case

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

> On Nov 30, 2017, at 3:54 PM, Xiaodi Wu wrote: > While we shouldn’t necessarily avoid a feature simply because it can be used > distastefully, consider something like this: > > public extension NSObject : DynamicMemberLookupProtocol, > DynamicCallableProtocol { … }

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

> On Nov 30, 2017, at 10:31 PM, Chris Lattner wrote: > > The Objective-C runtime does not track the type of members or methods. Ok, this statement isn’t factually true: I’ll admit that there are two related things to this: the GNU ObjC runtime does track some method types,

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

> On Nov 30, 2017, at 10:26 PM, Slava Pestov <spes...@apple.com> wrote: > > > >> On Nov 30, 2017, at 10:23 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The differ

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

> On Nov 30, 2017, at 6:15 AM, Matthew Johnson wrote: >> >> I think better interoperability with Python (and other OO languages in >> widespread use) is a good goal, and I agree that the implementation of the >> feature described is straight-forward and not terribly

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

On Nov 30, 2017, at 3:46 AM, Matt Diephouse wrote: > The examples in the proposal are very shallow, highlighting single lookups. > But what are the types of the returned values? The Python example is recursive: PyVal is returned and is the source of

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

Hi Doug, Thank you for the detailed email. I have been traveling today, so I haven’t had a chance to respond until now. I haven’t read the down-thread emails, so I apologize if any of this was already discussed: > I think better interoperability with Python (and other OO languages in >

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 29, 2017, at 12:46 AM, Brent Royal-Gordon > wrote: > >> On Nov 28, 2017, at 8:35 PM, Chris Lattner wrote: >> >> We’ve had a lot of discussions over the years about how to balance >> simplicity vs power, implicitness vs explicitness,

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

is one in the Python interop layer that I’m working on: it is a separate type that vends all the Python builtins. It returns them as PyVal's. -Chris > > >> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolut

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

> On Nov 28, 2017, at 8:57 PM, Slava Pestov <spes...@apple.com> wrote: > > Hi Chris, > >> On Nov 28, 2017, at 8:54 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> “post.

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

> On Nov 28, 2017, at 10:12 AM, Paul Cantrell wrote: > Chris wrote: >> Paul wrote: >>> An “always use parens” bridge to Ruby has bad ergonomics >>> Zero-arg Ruby methods are a mixture of property-like things that would >>> certainly not use parens in Swift, and function-like

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

> On Nov 27, 2017, at 9:03 PM, Magnus Ahltorp wrote: > Also, if the bridge author wants to return optionals all the time, that is > possible, right? Yes, absolutely. An example of that is already in the proposal. -Chris ___

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

> On Nov 28, 2017, at 5:58 PM, Greg Parker via swift-evolution > wrote: > > >> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution >> > wrote: >> >> You're saying that there is universally

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

> On Nov 28, 2017, at 1:55 PM, Ben Rimmington wrote: > > I suggest using different subscripts for function/method calls and properties: > > * `value(...)` ==> `value[dynamicFunction: ""](...)` > * `value.name(...)` ==> `value[dynamicFunction: "name"](...)` > *

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 27, 2017, at 7:31 PM, Xiaodi Wu wrote: > > Better yet, since we previously started to require “@objc dynamic” instead of > “dynamic” with the notion that perhaps there would be some future non-ObjC > dynamism, we *could* have it spelt “dynamic member(_:)”. I’m

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 27, 2017, at 6:21 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Just to

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

tation details, but I think the overall > approach. I’d like it better if we have provisions to create these types of > tools outside of the compiler, but that’s another topic. > > -David > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> <swift-evo

  1   2   3   4   5   6   7   8   9   10   >