Re: [swift-evolution] constant var

> 14 Dec. 2017 09:52 Inder Kumar Rathore . via swift-evolution > wrote: > > class MyClass { > private var myDict = [String : String]() > > func addMemebr() { > self.myDict["key"] = "value" // Ok for me > } > > func anotherFunc() { > self.myDict

Re: [swift-evolution] constant var

> 14 Dec. 2017 17:52 Inder Kumar Rathore . via swift-evolution > wrote: > > class MyClass { > private var myDict = [String : String]() > > func addMemebr() { > self.myDict["key"] = "value" // Ok for me > } > > func anotherFunc() { > self.myDict

Re: [swift-evolution] Optional Argument Chaining

> 12 Dec. 2017 02:58 Jared Khan wrote: > > 2. It felt natural to me. It’s analogous to the existing optional chaining > scenarios and composes nicely. I think it’s about as understandable as > existing chaining, a newbie would have to look it up to discover its meaning. >

Re: [swift-evolution] Optional Argument Chaining

> 12 Dec. 2017 01:30 Jared Khan via swift-evolution > wrote: > > I'd like to propose a syntax addition that acts to ease some things that I > believe should fall under the umbrella of 'optional chaining'. Optional > chaining allows us to access the properties of an

Re: [swift-evolution] [Pitch] Generalized supertype constraints

Mutation is more or less modeled as reassignment in Swift, there is no difference between a variable that can be mutated and one that can be reassigned (right?). There are however differences between inout's real behaviour and what some might expect; some might expect that it is modified at

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

> 6 Dec. 2017 16:51 Jonathan Hull via swift-evolution > wrote: > > Ok, I have changed my mind about the need for a marker, and will accept the > proposal as-is. I realized that these dynamic member lookup types can just > be made inner types, and so I can easily

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

> 6 Dec. 2017 04:13 Thorsten Seitz wrote: > > I just wanted to add that the single purpose of a static type system is to > ensure that the methods being called on a receiver are present at runtime and > take arguments of the types known at compile time. Of course the type

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

> 5 Dec. 2017 01:08 Benjamin G via swift-evolution > wrote: > > Unless DynamicLookup is used to circumvent every compiler warning or errors > thrown at you by the language because your design is unsound. Something like > "ho, yeah swift generics and protocols

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

> 5 Dec. 2017 02:25 Joe DeCapo via swift-evolution > wrote: > >> On Dec 4, 2017, at 11:15 AM, Tino Heth <2...@gmx.de> wrote: >> >>> >>> This is a bridge to allow easy access to the vast number of libraries that >>> currently exist in those dynamic language

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

> 4 Dec. 2017 11:17 Letanyan Arumugam via swift-evolution > wrote: > > The most minimal way of marking expressions in a way I could think of that > would also remove anyones notion of "this code is fully supported static > Swift code” would be to use the currently

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

> 4 Dec. 2017 03:54 Thorsten Seitz via swift-evolution > wrote: > > The difference is that IUOs are marked by a "!“ whereas dynamic member > lookups look just like normal member lookups but unlike them can fail. IUOs are not marked with an "!" by the caller, that's

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

> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution > 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 :-) > > Further, I incorporated some of the conversation

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

> 28 Nov. 2017 00:57 Mathew Huusko V wrote: > > 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

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

> 27 Nov. 2017 22:38 Mathew Huusko V via swift-evolution > 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

Re: [swift-evolution] [Pitch] Raw mode string literals

> 24 Nov. 2017 08:33 Chris Lattner via swift-evolution > wrote: > > 2) I’d like to explore the idea of making // syntax be *patterns* instead of > simply literals. As a pattern, it should be possible to bind submatches > directly into variable declarations,

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

> 29 Aug. 2016 23:15 DifferentApps info wrote: > > Thanks for your pattern suggestion. > But it would be also possible to switch between implementations with the > proposed syntax as shown bellow: > > /{ > > }/ > do { > > } No, that would not be

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

> 27 Aug. 2016 21:03 Andre Ponzo via swift-evolution > wrote: > > 1) Advantages of disabled code ( /{ ... } ) instead of commented-out code (/* > ... */): > 2) Advantages of /{ ... } instead of "if false { ... }": What are the advantages of this compared to

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

> 27 Aug. 2016 15:58 Charlie Monroe via swift-evolution > wrote: > Now, you need to do: > > users.sorted({ > guard let firstName = $0.0.lastName else { > return true > } > > guard let secondName = $0.1.lastName else { >

Re: [swift-evolution] InternalString class for easy String manipulation

> 18 Aug. 2016 07:40 Félix Cloutier via swift-evolution > wrote: > >> In Félix’s case, I would expect to have to ask for a mail-friendly >> representation of his name, just like you have to ask for a >> filesystem-friendly representation of a filename regardless of

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

> This proposal adds basic usability for working with raw memory without > breaking source. The need to provide higher level API for working with raw > memory buffers has always been evident, but making improvements in this area > depended on first introducing `UnsafeRawPointer`. It was not

Re: [swift-evolution] ABI in Layman's terms?

> 11 Aug. 2016 22:57 Slava Pestov via swift-evolution > wrote: > > - The first axis is the machine-level calling conventions and memory layout. > For example, what registers to pass function arguments and returns in, the > rules for alignment and padding of fields

Re: [swift-evolution] [Swift4] Priorities and Sugar

> 30 Jul 2016 02:38 Chris Lattner wrote: > >> On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp wrote: >> >>> 30 Jul 2016 02:17 Chris Lattner via swift-evolution >>> wrote: >>> >>> Moving into early Swift 4 planning and development, we

Re: [swift-evolution] [Swift4] Priorities and Sugar

> 30 Jul 2016 02:17 Chris Lattner via swift-evolution > wrote: > > Moving into early Swift 4 planning and development, we have no desires beyond > what I listed in the big email. There is no long laundry list, it is a few > specific (big!) topics. > > We

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API

> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through > July 4, 2016. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md I have not had time for a full review, but I have a question about the

Re: [swift-evolution] Prohibit invisible characters in identifier names

> 25 June 2016 06:13 Charlie Monroe wrote: > >> >> On Jun 25, 2016, at 12:21 AM, Magnus Ahltorp wrote: >> >> As far as I can see, forcing the programmer to write identifiers in an >> only-ASCII language, and requiring that identifier names have to be