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

> … > > In Ruby, `myObj.name()` is equivalent to `myObj.name`, and either works. In > Swift, I don’t see that it’s possible to make both work with Chris’s proposal. IIUC, the goal is not to make swift look and behave the same as ruby or python, but to be able to use ruby or python object in a

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

> On Nov 17, 2017, at 12:08 AM, Brent Royal-Gordon > wrote: > >> On Nov 16, 2017, at 1:44 PM, Paul Cantrell > > wrote: >> >> In the example you bring up: >> >>> you can write `def someMember` and `def

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

On Fri, Nov 17, 2017 at 7:11 PM, Brent Royal-Gordon wrote: > On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > But actually, Int.random followed by % is the much bigger issue and a very > good cautionary tale for why

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] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 17, 2017, at 15:20, Ben Langmuir wrote: > > Hi Jordan, > > First off, this is clearly the model we should have had all along ;-) That > said, I have a concern about source-compat and our ability to automatically > migrate code impacted by this change. >>

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

> On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution > wrote: > > But actually, Int.random followed by % is the much bigger issue and a very > good cautionary tale for why T.random is not a good idea. Swift should help > users do the correct thing, and

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

On Fri, Nov 17, 2017 at 18:10 Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > That’s the point. Using “Int.random(in: 0...9)” gives you a result that > has an equal chance of being any integer between zero and nine, while > “Int.random % 9” does not. (...and nor does

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

That’s the point. Using “Int.random(in: 0...9)” gives you a result that has an equal chance of being any integer between zero and nine, while “Int.random % 9” does not. On Fri, Nov 17, 2017 at 17:30 Jonathan Hull wrote: > Just to play devil’s advocate, wouldn’t they see

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

Just to play devil’s advocate, wouldn’t they see random(in:) in the autocomplete when typing ‘random’? Thanks, Jon > On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution >

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

Hi Jordan, First off, this is clearly the model we should have had all along ;-) That said, I have a concern about source-compat and our ability to automatically migrate code impacted by this change. > Source compatibility > > This makes existing code invalid in Swift 5, which is a source

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

> On Nov 17, 2017, at 4:09 PM, Xiaodi Wu via swift-evolution > wrote: > > > Certainly it's hard to defend Date.random (and yes, it might be useful for a > fuzzer, but that's a very niche use case--and in that case the fuzzer should > probably also generate

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

On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > > > Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution < > swift-evolution@swift.org> a écrit : > > > > If we go back to your example, you never call FixedWidthInteger.random >

[swift-evolution] [Idea] [Pitch] Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching

## Title Add `match` statement as `switch`-like syntax alternative to `if case` pattern matching ## Summary: The syntax of the `switch` statement is familiar, succinct, elegant, and understandable. Swift pattern-matching tutorials use `switch` statements almost exclusively, with small sections

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

I agree with all your points, but that’s if we were implementing a randomness source. What we’re providing is a random number generator that takes some randomness from a source and uses that to give the user an actual number it knows about. That differs from a randomness source because a

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

> On Nov 16, 2017, at 8:12 PM, Alejandro Alonso via swift-evolution > wrote: > > While this could work, I don’t believe this aligns with Swift. > SecRandomCopyBytes and arc4random_buf do it this way because of the languages > they were built in, and for

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

I can think of many cases where you actually need a random color, not because it doesn’t look good, but because you need a color you don’t have. The proposed solution most definitely includes a range based random api for those who don’t need the full domain (0 ..< 10).random. What I’m trying

Re: [swift-evolution] [Pitch] Synthesizing Concurrency: A Pitch For High-Level Abstractions & Low-Level Intelligence

+1 Howard, at least in the form of ‘let’ constants Swift ensures (or assumes, not really clear on that) that memory access will not conflict. Updated gist, to mention that and remove any implementation details relative to constants, however ‘async’s (and ‘sync's) with returns are still present

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

I agree with this. The only app-based use case I can think of for a full-range random value would be to construct a unique temporary file name. But that’s easily replaced with UUID().uuidString or mkstemp() (or whatever it’s called). Dave Sent from my iPhone > On Nov 17, 2017, at 9:10 AM,

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

> Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution > a écrit : > > If we go back to your example, you never call FixedWidthInteger.random > either, you call range.random. Does this mean integer types shouldn’t have > .random? No, because it means get a

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

If we go back to your example, you never call FixedWidthInteger.random either, you call range.random. Does this mean integer types shouldn’t have .random? No, because it means get a random number from it’s internal range (alias to (min ... max).random). I think we can all agree that

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

I’d be more than happy to help as well! > On Nov 16, 2017, at 12:39 AM, Nicole Jacque via swift-dev > wrote: > > As Ted Kremenek has previously announced, we are in the process of moving the > Swift mailing lists to Discourse. Previously the discussion was mostly about >

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

> On Nov 16, 2017, at 10:08 PM, Brent Royal-Gordon via swift-evolution > wrote: > > So, let me sketch a vague idea of how this might work. This is definitely not > fully baked, but it might give you an idea. Looking at this again, I realize I accidentally generated