> 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 = [String : String]() // Not
> 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 = [String : String]() // Not
> 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.
> What are your though
> 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 optional value and return
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
the
> 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 create the .dynamic behavior i
> 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 system
> does not gua
> 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 aren't really working fine togeth
> 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 domains, and to ease the
>>> trans
> 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 reserved ‘ (Single quote).
>
> 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 what makes them implicit.
T
> 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 with Matthew into the
> pro
> 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 true. Yes
> "+" (/other
> 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 syntactic/sugar conversion has been
> 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, eliminating the need to count pare
> 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 sufficient. A constructed example:
#if tr
> 29 Aug. 2016 22:16 DifferentApps info wrote:
>
> The advantage is that you do not need to define a conditional flag for the
> #if.
The good news is, you don't.
#if false
print("Disabled code")
#endif
which is a time-tested way of writing C code (using #if 0).
From the Swift changelog, wh
> 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 conditional compilation (#if)?
/M
> 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 {
> return false
> }
> 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 what the
>> internal repres
> 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 clea
> 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 in an aggregate type, which e
> 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 have no desires
>>> beyond what I listed in the big email. T
> 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 specifically do not want a surge of p
> 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
> 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
>> meaningful to the programmer means tha
> 21 June 2016 16:48 Vladimir.S via swift-evolution wrote:
>
> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:
>>
>>> On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution
>>> wrote:
>>>
Perhaps stupid but: why was Swift designed to accept most Unicode
char
27 matches
Mail list logo