[swift-evolution] Optional Argument Chaining

[Jared Khan via swift-evolution]

Hi all,

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 nil 
if any link in that chain breaks. I propose we introduce syntax to allow 
similar chaining when passing optional valued parameters to functions that 
expect that parameter to be non-optional.

The example below is taken from a project I'm working on at the moment:


// Current
let readme: Markdown?
if let rawMarkdown = String(contentsOfFile: "README.md") {
readme = Markdown(string: rawMarkdown)
} else {
readme = nil
}
In this example we want to perform an operation, the initialisation of a 
'Markdown' type, with our raw text if it exists and get nil otherwise. This is 
rather verbose

I propose the following syntax for an alternative:


// Proposed alternative
let readme = Markdown(string: String(contentsOfFile: "README.md")?)

The ? is familiar in its use for optional chaining.

This would act like syntactic sugar for the flatMap method on Optional. For 
example:

(where `john` is of a `Person` type with a property `address: Address?`)
// func getZipCode(fromAddress address: Address) -> ZipCode
getZipCode(fromAddress: john.address?)

// Would be equivalent to…
john.address.flatMap {
getZipCode($0)
}
An example with multiple parameters:

// func getPostageEstimate(source: Address, destination: Address, weight: 
Double) -> Int
getPostageEstimate(source: john.address?, destination: alice.address?, weight: 
2.0)

// Equivalent to
john.address.flatMap { freshVar1 in
alice.address.flatMap { freshVar2 in
getPostageEstimate(source: freshVar1, destination: freshVar2, 
weight: 2.0)
}
}

// Or equally:
{
guard let freshVar1 = john.address,
let freshVar2 = alice.address else {
return nil
}

return getPostageEstimate(source: freshVar1, destination: freshVar2, 
weight: 2.0)
}()
This would only be allowed when the parameter doesn’t already accept Optionals 
and when the chained value is in fact an optional. We’d want to consider 
emitting at least the following errors/warnings in the given scenarios:


let result = myFunc(3?)
// error: cannot use optional chaining on non-optional value of type 'Int'

// func myFunc2(x: String?) -> String
let result = myFunc2(x: john.address?)
// error: cannot use optional argument chaining on argument of optional type
let result = myFunc(nil?)
// warning: optional argument chaining with nil literal always results in nil

Seeking your thoughts on this idea, the specific syntax, and more use case 
examples.

Best,

Jared___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Magnus Ahltorp via swift-evolution]

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 same time (and as many times) as if the function was inlined.

struct F {
var a : Int {
didSet {
print("set \(a)")
}
}
}

func setTimes(a: inout Int, times: Int) {
for _ in 1...times {
a += 1
}
}

var foo = F(a: 0)

// prints set 1 … set 10
for _ in 1...10 {
foo.a += 1
}

setTimes(a: , times: 10) // only prints set 20


However, your generalization is already possible, just change the function head 
to:

func foo(_ p: inout E)

which, if we add a member to the protocol and something meaningful for the 
function to do becomes something like this:

protocol P { var a : Int {get set} }

func foo(_ p: inout E) {
p.a += 1
}

struct F : P { var a : Int }

var f = F(a: 0)

foo()
print(f)

Was there some other problem you were trying to solve that can't be solved by 
doing this?

/Magnus

> 11 Dec. 2017 03:49 Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I see, that makes totally sense. I thought about `inout` only in terms of 
> mutation not reassignment from within the scope itself.
> 
> 
> Am 10. Dezember 2017 um 17:56:56, Jonathan Keller (jkeller...@icloud.com) 
> schrieb:
> 
>> No, inout should *not* be covariant, since foo can assign any subtype of P 
>> to its parameter, not just F:
>> 
>> protocol P {}
>> struct F: P {}
>> struct G: P {}
>> 
>> func foo(_ p: inout P) {
>> p = G()
>> }
>> 
>> var f = F()
>> foo() // assigns a value of type G to a variable of type F
>> 
>> From Jonathan
>> 
>> On Dec 10, 2017, at 12:51 AM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>>> Hello Matthew, I have more more question about the generalized supertype 
>>> constraints. Does the generalization also covers inout? I found a really 
>>> annoying case with inout.
>>> 
>>> protocol P {}
>>> 
>>> func foo(_ p: inout P) {
>>> print(p)
>>> }
>>> 
>>> struct F : P {}
>>> 
>>> var f = F()
>>> 
>>> foo() // won't compile until we explicitly write `var f: P = F()`
>>> 
>>> Shouldn’t we allow inout to have subtypes as well, like inout F : inout P?
>>> 
>>> This is actually one of the pain points with the generic version of the 
>>> print function. We cannot pass an arbitrary TextOutputStream to it without 
>>> sacrificing the type. I doubt the generic print function is justified, 
>>> because TextOuputStream does not have associated types nor a Self 
>>> constraint. Furthermore it forces you to create a custom type-erased 
>>> wrapper that can hold an arbitrary TextOutputSteram.
>>> 
>>> If this is part of a totally different topic, I’ll move it in it’s own 
>>> thread.
>>> 
>>> 
>>> 
>>> Am 2. Dezember 2017 um 19:03:24, Matthew Johnson via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 This thread received very light, but positive feedback.  I would really 
 like to see this feature added and am willing to draft and official 
 proposal but am not able to implement it.  If anyone is interested in 
 collaborating just let me know.
 
 
> On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> One of the most frequent frustrations I encounter when writing generic 
> code in Swift is the requirement that supertype constraints be concrete.  
> When I mentioned this on Twitter 
> (https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
> mentioned that this feature is smaller and mostly straightforward to 
> design and implement 
> (https://twitter.com/dgregor79/status/929975472779288576).
> 
> I currently have a PR open to add the high-level description of this 
> feature found below to the generics manifesto 
> (https://github.com/apple/swift/pull/13012):
> 
> Currently, supertype constraints may only be specified using a concrete 
> class or protocol type.  This prevents us from abstracting over the 
> supertype.
> 
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
> 
> In the above example `Base` may be any type.  `Derived` may be the same 
> as `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
> supported by Swift should be supported in this context including, but not 
> limited to, classes and subclasses, existentials and conforming concrete 
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
> `((Derived) -> Void)`, etc.
> 
> Generalized supertype constraints would be accepted in all syntactic 
> locations where generic constraints are accepted.
> 
> I would like to see 

Re: [swift-evolution] Optional Argument Chaining

[Charles Augustine via swift-evolution]

I don’t think that solves the same thing.  The problem is I read it is to allow 
some sort of short hand to be able to pass optional types as parameters into 
methods / initializers that do not take optional types.  The result of that 
method / initializer being nil if any of said parameters were nil or a typical 
result otherwise.  Based on your example I think it’s identical to the existing 
?? operator, is it not?

As per the suggested syntax, I do think that we would want to be able to 
control this feature on a per parameter basis, so it would make sense to have 
the ? operator placed after the parameter that needed to be unwrapped.  This 
would also be more consistent with the usage of the existing syntax.

— Charles

> On Dec 11, 2017, at 9:37 AM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> You can create a binary operator that tests the left-hand operand for nil, 
> and passes the unwrapped value to the right-hand operand (a function taking 
> one value), this operator can be made left-associative to allow chaining.
> 
> let m = String(contentsOfFile: "README.md") ??? Markdown 
> where ??? is the operator described above.
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk  <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
> 
> * http://agilesolutionspace.blogspot.com/ 
> 
> 
> On Dec 11, 2017, at 9:07 AM, Magnus Ahltorp via swift-evolution 
> > wrote:
> 
>> 
>>> 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 
>>> nil if any link in that chain breaks. I propose we introduce syntax to 
>>> allow similar chaining when passing optional valued parameters to functions 
>>> that expect that parameter to be non-optional.
>> 
>> 1. Am I right in assuming that you propose that the suffix operator "?" 
>> would make the result of the surrounding method/function call optional, so 
>> that a(b(c?)) would make the result of the "b" function call optional, but 
>> not the "a" function call, and that it would be a(b(c?)?) if we would like 
>> to propagate this two levels?
>> 
>> 2. If that is the case, is that understandable/neat enough? How common would 
>> you expect this to be?
>> 
>> 3. For some reason, (in current Swift) the suffix operator "?" seems to be 
>> allowed in intra-expression syntax, and only fails when the inter-expression 
>> syntax is checked for optionality congruence. Is there a reason for this? I 
>> would have expected that the congruence error "cannot use optional chaining 
>> on non-optional value of type" would never be seen for a lone "?", since the 
>> error message "'?' must be followed by a call, member lookup, or subscript" 
>> would always be displayed first if it was checked first. The "." operator 
>> checks intra-expression syntax first, before checking congruence. Is this a 
>> sign that "?" as a suffix operator is already somewhat operational as an 
>> operator for optional types? I have a faint recollection that it was doing 
>> something in earlier versions of Swift.
>> 
>> /Magnus
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Magnus Ahltorp via swift-evolution]

> 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 
> nil if any link in that chain breaks. I propose we introduce syntax to allow 
> similar chaining when passing optional valued parameters to functions that 
> expect that parameter to be non-optional.

1. Am I right in assuming that you propose that the suffix operator "?" would 
make the result of the surrounding method/function call optional, so that 
a(b(c?)) would make the result of the "b" function call optional, but not the 
"a" function call, and that it would be a(b(c?)?) if we would like to propagate 
this two levels?

2. If that is the case, is that understandable/neat enough? How common would 
you expect this to be?

3. For some reason, (in current Swift) the suffix operator "?" seems to be 
allowed in intra-expression syntax, and only fails when the inter-expression 
syntax is checked for optionality congruence. Is there a reason for this? I 
would have expected that the congruence error "cannot use optional chaining on 
non-optional value of type" would never be seen for a lone "?", since the error 
message "'?' must be followed by a call, member lookup, or subscript" would 
always be displayed first if it was checked first. The "." operator checks 
intra-expression syntax first, before checking congruence. Is this a sign that 
"?" as a suffix operator is already somewhat operational as an operator for 
optional types? I have a faint recollection that it was doing something in 
earlier versions of Swift.

/Magnus

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[C. Keith Ray via swift-evolution]

You can create a binary operator that tests the left-hand operand for nil, and 
passes the unwrapped value to the right-hand operand (a function taking one 
value), this operator can be made left-associative to allow chaining.

let m = String(contentsOfFile: "README.md") ??? Markdown 
where ??? is the operator described above.

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Dec 11, 2017, at 9:07 AM, Magnus Ahltorp via swift-evolution 
>  wrote:
> 
> 
>> 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 
>> nil if any link in that chain breaks. I propose we introduce syntax to allow 
>> similar chaining when passing optional valued parameters to functions that 
>> expect that parameter to be non-optional.
> 
> 1. Am I right in assuming that you propose that the suffix operator "?" would 
> make the result of the surrounding method/function call optional, so that 
> a(b(c?)) would make the result of the "b" function call optional, but not the 
> "a" function call, and that it would be a(b(c?)?) if we would like to 
> propagate this two levels?
> 
> 2. If that is the case, is that understandable/neat enough? How common would 
> you expect this to be?
> 
> 3. For some reason, (in current Swift) the suffix operator "?" seems to be 
> allowed in intra-expression syntax, and only fails when the inter-expression 
> syntax is checked for optionality congruence. Is there a reason for this? I 
> would have expected that the congruence error "cannot use optional chaining 
> on non-optional value of type" would never be seen for a lone "?", since the 
> error message "'?' must be followed by a call, member lookup, or subscript" 
> would always be displayed first if it was checked first. The "." operator 
> checks intra-expression syntax first, before checking congruence. Is this a 
> sign that "?" as a suffix operator is already somewhat operational as an 
> operator for optional types? I have a faint recollection that it was doing 
> something in earlier versions of Swift.
> 
> /Magnus
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Jared Khan via swift-evolution]

1. Correct

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 thoughts on this particular syntax (ignoring 3. momentarily)? Hopefully 
others in this thread can share their views too.
As for how common I’d expect it to be, it’s something I’ve run into myself a 
few times. Again, I hope members of this list can give their view on if this 
would be useful to them.

3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ has 
never been available as a postfix operator. Perhaps I’m missing your point, 
could you demonstrate where it is allowed?

Best,
Jared

> On 11 Dec 2017, at 17:07, Magnus Ahltorp  wrote:
> 
> 
>> 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 
>> nil if any link in that chain breaks. I propose we introduce syntax to allow 
>> similar chaining when passing optional valued parameters to functions that 
>> expect that parameter to be non-optional.
> 
> 1. Am I right in assuming that you propose that the suffix operator "?" would 
> make the result of the surrounding method/function call optional, so that 
> a(b(c?)) would make the result of the "b" function call optional, but not the 
> "a" function call, and that it would be a(b(c?)?) if we would like to 
> propagate this two levels?
> 
> 2. If that is the case, is that understandable/neat enough? How common would 
> you expect this to be?
> 
> 3. For some reason, (in current Swift) the suffix operator "?" seems to be 
> allowed in intra-expression syntax, and only fails when the inter-expression 
> syntax is checked for optionality congruence. Is there a reason for this? I 
> would have expected that the congruence error "cannot use optional chaining 
> on non-optional value of type" would never be seen for a lone "?", since the 
> error message "'?' must be followed by a call, member lookup, or subscript" 
> would always be displayed first if it was checked first. The "." operator 
> checks intra-expression syntax first, before checking congruence. Is this a 
> sign that "?" as a suffix operator is already somewhat operational as an 
> operator for optional types? I have a faint recollection that it was doing 
> something in earlier versions of Swift.
> 
> /Magnus
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Matthew Johnson via swift-evolution]

It’s worth mentioning that the problem this thread is discussing can be 
generalized to idioms / applicative.  The specific case here is for Optional 
but many other types could benefit from an elegant syntactic solution to this 
problem.  It might be worth exploring a more general solution.  Here’s a link 
to how this is handled in Idris: 
http://docs.idris-lang.org/en/latest/tutorial/interfaces.html#idiom-brackets 
.

Matthew

> On Dec 11, 2017, at 12:01 PM, Jared Khan via swift-evolution 
>  wrote:
> 
> 1. Correct
> 
> 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 thoughts on this particular syntax (ignoring 3. momentarily)? 
> Hopefully others in this thread can share their views too.
> As for how common I’d expect it to be, it’s something I’ve run into myself a 
> few times. Again, I hope members of this list can give their view on if this 
> would be useful to them.
> 
> 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ has 
> never been available as a postfix operator. Perhaps I’m missing your point, 
> could you demonstrate where it is allowed?
> 
> Best,
> Jared
> 
>> On 11 Dec 2017, at 17:07, Magnus Ahltorp  wrote:
>> 
>> 
>>> 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 
>>> nil if any link in that chain breaks. I propose we introduce syntax to 
>>> allow similar chaining when passing optional valued parameters to functions 
>>> that expect that parameter to be non-optional.
>> 
>> 1. Am I right in assuming that you propose that the suffix operator "?" 
>> would make the result of the surrounding method/function call optional, so 
>> that a(b(c?)) would make the result of the "b" function call optional, but 
>> not the "a" function call, and that it would be a(b(c?)?) if we would like 
>> to propagate this two levels?
>> 
>> 2. If that is the case, is that understandable/neat enough? How common would 
>> you expect this to be?
>> 
>> 3. For some reason, (in current Swift) the suffix operator "?" seems to be 
>> allowed in intra-expression syntax, and only fails when the inter-expression 
>> syntax is checked for optionality congruence. Is there a reason for this? I 
>> would have expected that the congruence error "cannot use optional chaining 
>> on non-optional value of type" would never be seen for a lone "?", since the 
>> error message "'?' must be followed by a call, member lookup, or subscript" 
>> would always be displayed first if it was checked first. The "." operator 
>> checks intra-expression syntax first, before checking congruence. Is this a 
>> sign that "?" as a suffix operator is already somewhat operational as an 
>> operator for optional types? I have a faint recollection that it was doing 
>> something in earlier versions of Swift.
>> 
>> /Magnus
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Xiaodi Wu via swift-evolution]

This topic has been discussed at least two and maybe more times in the
past. It’s hard for me to post links at the moment, but it should be
possible to find on Google.

One major challenge to this idea, for which no satisfactory answer has been
achieved after all these years, is the following issue:

f(g()?, h()?, i(), j()?)?

If g() evaluates to nil, is h() called or not? How about i(), which is not
failable? Since any function or property access can have side effects, in
what order are the arguments evaluated, and how does one reason about this
code flow?

To my mind, in the absence of an intuitive answer to the above—which does
not appear to be possible—this idea is not feasible.
On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > 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 thoughts on this particular syntax
> (ignoring 3. momentarily)? Hopefully others in this thread can share their
> views too.
>
> Chaining methods is linear, while nesting fills a similar purpose when we
> use function calls. This of course affects the way existing Swift code is
> written, but that is something we have to live with if we want to use
> familiar syntax patterns. However, I think we have to consider this
> difference in this case, since the syntax becomes more convoluted. Your
> suggestion is definitely not as easy to read as the optional chaining
> syntax, and maybe it can't be.
>
> > As for how common I’d expect it to be, it’s something I’ve run into
> myself a few times. Again, I hope members of this list can give their view
> on if this would be useful to them.
>
> I don't have any real examples, but I certainly think that I have run into
> it, so I'm quite open to solving the problem. For me, it is probably only a
> matter of finding a syntax that is acceptable.
>
> > 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’
> has never been available as a postfix operator. Perhaps I’m missing your
> point, could you demonstrate where it is allowed?
>
> I did not expect that you would be able to answer that, it was more a
> question directed to people who are more connected to the inner workings of
> the parsing of Swift than I am. It is not allowed, but the error message is
> not the one I expect, something that gives me a hint that it does have some
> meaning early in the parsing.
>
> /Magnus
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Magnus Ahltorp via swift-evolution]

> 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 thoughts on this particular syntax (ignoring 3. momentarily)? 
> Hopefully others in this thread can share their views too.

Chaining methods is linear, while nesting fills a similar purpose when we use 
function calls. This of course affects the way existing Swift code is written, 
but that is something we have to live with if we want to use familiar syntax 
patterns. However, I think we have to consider this difference in this case, 
since the syntax becomes more convoluted. Your suggestion is definitely not as 
easy to read as the optional chaining syntax, and maybe it can't be.

> As for how common I’d expect it to be, it’s something I’ve run into myself a 
> few times. Again, I hope members of this list can give their view on if this 
> would be useful to them.

I don't have any real examples, but I certainly think that I have run into it, 
so I'm quite open to solving the problem. For me, it is probably only a matter 
of finding a syntax that is acceptable.

> 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ has 
> never been available as a postfix operator. Perhaps I’m missing your point, 
> could you demonstrate where it is allowed?

I did not expect that you would be able to answer that, it was more a question 
directed to people who are more connected to the inner workings of the parsing 
of Swift than I am. It is not allowed, but the error message is not the one I 
expect, something that gives me a hint that it does have some meaning early in 
the parsing.  

/Magnus

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Adrian Zubarev via swift-evolution]

This is an interesting example but I think the solution might be simple if we 
try to desugar it.

// example
f(g()?, h()?, i(), j()?)?

// desugared
let/var someF: SomeType?
if let someG = g(),  let someH = h(), let someJ = j() {
someF = f(someG, someH, i(), someJ)
} else {
someF = nil
}
Final syntax aside, let’s use the optional function syntax from obj-c world 
here for a moment: f?(g(), h(), i(), j(), k()) where the function signature 
would look like func f(_: G, _: H, _: I, _: J, _: K?).

Only if the parameter type is non-optional and the argument is optional then we 
can desugar it like this:

let/var someF: SomeType?
if let someG = g(),  let someH = h(), let someJ = j() {
someF = f(someG, someH, i(), someJ, k())
} else {
someF = nil
}
No need to unwrap the result from k() here.




Am 11. Dezember 2017 um 20:28:52, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

This topic has been discussed at least two and maybe more times in the past. 
It’s hard for me to post links at the moment, but it should be possible to find 
on Google.

One major challenge to this idea, for which no satisfactory answer has been 
achieved after all these years, is the following issue:

f(g()?, h()?, i(), j()?)?

If g() evaluates to nil, is h() called or not? How about i(), which is not 
failable? Since any function or property access can have side effects, in what 
order are the arguments evaluated, and how does one reason about this code flow?

To my mind, in the absence of an intuitive answer to the above—which does not 
appear to be possible—this idea is not feasible.
On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution 
 wrote:

> 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 thoughts on this particular syntax (ignoring 3. momentarily)? 
> Hopefully others in this thread can share their views too.

Chaining methods is linear, while nesting fills a similar purpose when we use 
function calls. This of course affects the way existing Swift code is written, 
but that is something we have to live with if we want to use familiar syntax 
patterns. However, I think we have to consider this difference in this case, 
since the syntax becomes more convoluted. Your suggestion is definitely not as 
easy to read as the optional chaining syntax, and maybe it can't be.

> As for how common I’d expect it to be, it’s something I’ve run into myself a 
> few times. Again, I hope members of this list can give their view on if this 
> would be useful to them.

I don't have any real examples, but I certainly think that I have run into it, 
so I'm quite open to solving the problem. For me, it is probably only a matter 
of finding a syntax that is acceptable.

> 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ has 
> never been available as a postfix operator. Perhaps I’m missing your point, 
> could you demonstrate where it is allowed?

I did not expect that you would be able to answer that, it was more a question 
directed to people who are more connected to the inner workings of the parsing 
of Swift than I am. It is not allowed, but the error message is not the one I 
expect, something that gives me a hint that it does have some meaning early in 
the parsing.

/Magnus

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Jared Khan via swift-evolution]

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
 


Thanks for this important point.

If you were to write this logic out by hand then you would short-circuit it and 
this is analogous to current chaining behaviour so to me evaluating left to 
right (as Swift usually does) and stopping at the first failed unwrap would 
make sense. I wouldn’t necessarily say it’s intuitive but I don’t think it’s 
really less intuitive than the current chaining behaviour. 

Jared

> On 11 Dec 2017, at 19:28, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This topic has been discussed at least two and maybe more times in the past.. 
> It’s hard for me to post links at the moment, but it should be possible to 
> find on Google.
> 
> One major challenge to this idea, for which no satisfactory answer has been 
> achieved after all these years, is the following issue:
> 
> f(g()?, h()?, i(), j()?)?
> 
> If g() evaluates to nil, is h() called or not? How about i(), which is not 
> failable? Since any function or property access can have side effects, in 
> what order are the arguments evaluated, and how does one reason about this 
> code flow?
> 
> To my mind, in the absence of an intuitive answer to the above—which does not 
> appear to be possible—this idea is not feasible.
> On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution 
> > wrote:
> 
> > 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 thoughts on this particular syntax (ignoring 3. 
> > momentarily)? Hopefully others in this thread can share their views too.
> 
> Chaining methods is linear, while nesting fills a similar purpose when we use 
> function calls. This of course affects the way existing Swift code is 
> written, but that is something we have to live with if we want to use 
> familiar syntax patterns. However, I think we have to consider this 
> difference in this case, since the syntax becomes more convoluted. Your 
> suggestion is definitely not as easy to read as the optional chaining syntax, 
> and maybe it can't be.
> 
> > As for how common I’d expect it to be, it’s something I’ve run into myself 
> > a few times. Again, I hope members of this list can give their view on if 
> > this would be useful to them.
> 
> I don't have any real examples, but I certainly think that I have run into 
> it, so I'm quite open to solving the problem. For me, it is probably only a 
> matter of finding a syntax that is acceptable.
> 
> > 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ 
> > has never been available as a postfix operator. Perhaps I’m missing your 
> > point, could you demonstrate where it is allowed?
> 
> I did not expect that you would be able to answer that, it was more a 
> question directed to people who are more connected to the inner workings of 
> the parsing of Swift than I am. It is not allowed, but the error message is 
> not the one I expect, something that gives me a hint that it does have some 
> meaning early in the parsing.
> 
> /Magnus
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Jared Khan via swift-evolution]

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
 


Thanks for this important point.

If you were to write this logic out by hand then you would short-circuit it and 
this is analogous to current chaining behaviour so to me evaluating left to 
right (as Swift usually does) and stopping at the first failed unwrap would 
make sense. I wouldn’t necessarily say it’s intuitive but I don’t think it’s 
really less intuitive than the current chaining behaviour. 

Jared

> On 11 Dec 2017, at 19:28, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This topic has been discussed at least two and maybe more times in the past.. 
> It’s hard for me to post links at the moment, but it should be possible to 
> find on Google.
> 
> One major challenge to this idea, for which no satisfactory answer has been 
> achieved after all these years, is the following issue:
> 
> f(g()?, h()?, i(), j()?)?
> 
> If g() evaluates to nil, is h() called or not? How about i(), which is not 
> failable? Since any function or property access can have side effects, in 
> what order are the arguments evaluated, and how does one reason about this 
> code flow?
> 
> To my mind, in the absence of an intuitive answer to the above—which does not 
> appear to be possible—this idea is not feasible.
> On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution 
> > wrote:
> 
> > 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 thoughts on this particular syntax (ignoring 3. 
> > momentarily)? Hopefully others in this thread can share their views too.
> 
> Chaining methods is linear, while nesting fills a similar purpose when we use 
> function calls. This of course affects the way existing Swift code is 
> written, but that is something we have to live with if we want to use 
> familiar syntax patterns. However, I think we have to consider this 
> difference in this case, since the syntax becomes more convoluted. Your 
> suggestion is definitely not as easy to read as the optional chaining syntax, 
> and maybe it can't be.
> 
> > As for how common I’d expect it to be, it’s something I’ve run into myself 
> > a few times. Again, I hope members of this list can give their view on if 
> > this would be useful to them.
> 
> I don't have any real examples, but I certainly think that I have run into 
> it, so I'm quite open to solving the problem. For me, it is probably only a 
> matter of finding a syntax that is acceptable.
> 
> > 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ 
> > has never been available as a postfix operator. Perhaps I’m missing your 
> > point, could you demonstrate where it is allowed?
> 
> I did not expect that you would be able to answer that, it was more a 
> question directed to people who are more connected to the inner workings of 
> the parsing of Swift than I am. It is not allowed, but the error message is 
> not the one I expect, something that gives me a hint that it does have some 
> meaning early in the parsing.
> 
> /Magnus
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Proposal and Timeline for Discourse Transition

[Nicole Jacque via swift-evolution]

Hi All-

Below is a summary proposal for our move to Discourse.  Please note, that 
unless there are any serious objections, we’d like to do this transition over 
the next weekend, so please communicate any issues that you may see as soon as 
possible.  Please file issues/comments/requests at bugs.swift.org 
 under the “Project Infrastructure” component for 
tracking.

A “prototype” of the forums showing the proposed structure is available for 
viewing at: http://swift.trydiscourse.com 
(Note: the final version will be hosted at forums.swift.org 
, and will be hosted over https.  Also note, we’re 
currently not supporting logins on the prototype site as we’re in the process 
of changing configurations.)

A big thank you to the volunteer members of the Swift Discourse working group 
for all of their input!

Timeline
In order to get the transition done, and work through any post-transition 
issues before many of the Swift infrastructure maintainers are on winter 
holiday break, we’d like to move forward soon — we propose starting the 
transition on the afternoon (US Pacific time) of Thursday, Dec. 14, and 
completing the transition by Dec 18 (Monday).  This means that email from the 
mailing lists would be disabled on the evening of the 14th in order to do a 
final import of mailing list data.  One final email would be sent out to the 
lists when the forums are up and ready for use.

The following @swift.org email lists will continue to function during and after 
the transition:
code-owners
conduct
swift-infrastructure

Forum Structure
After discussion with the Swift Discourse working group, we’ve slightly 
re-structured the forum, as opposed to simply mirroring the existing mailing 
list categories.  In Discourse, every topic must have a category, and it can 
have only one category. There will be four main categories, Evolution, 
Development, Using Swift, and Site Feedback.  The Evolution and Development 
categories will have a number of subcategories as follows:

Evolution: Announce, Pitches, Proposal Reviews, Discussion
Development: Compiler, Standard Library, Core Libraries, Package Manager, LLDB, 
Server, LLBuild, CI Notifications, Announcements

Some of these categories, such as the announcement and CI Notification 
sub-categories  may only allow new topics to be posted by forum administrators.

In addition to categories, forum posts can also be categorized by use of tags.  
A forum post can have many different tags added by the poster.  This is a great 
way to make it easy to find posts relating to certain topics, and to mark 
topics of interest (such as issues relating to specific projects) so that they 
can be easily found.

Accounts
Accounts can be set up using either email registration, or GitHub accounts.  
For those who have previously sent messages to the various Swift mailing lists, 
a staged account will already be set up, and there will be a process to take 
control of the account, provided you still have control of that email address.  
Note: Login functionality is not available with the swift.trydiscourse.com 
 staged site.

Within the forums, users can be tagged as “@Username” and can get notifications 
based on that tagging.

Email
You can choose to get email notifications for tracked categories tags, and can 
also choose to mute certain categories or topics within tracked categories.  
Replies via email to forum topics will be posted in the forums.  In order to 
create new topics via email, there will be an email address corresponding to 
each category/subcategory (similar to a mailing list email address) that can be 
used.

Code of Conduct
All forum activity is expected to conform to the Swift Code of Conduct.  The 
Code of Conduct will be prominently posted on the site. Violations can be 
anonymously flagged via the forum for review by administrators.

Upvoting
The Discourse forums have a “like” button which can be used to upvote a topic 
or reply, and the prominence of a post within a category reflects this.

FAQ
At the time when we go live, a FAQ will be posted with common questions, 
procedures, and links.  (for example setting up email notifications) ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Slava Pestov via swift-evolution]

> 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
>  
> 
> 
> Thanks for this important point.
> 
> If you were to write this logic out by hand then you would short-circuit it 
> and this is analogous to current chaining behaviour so to me evaluating left 
> to right (as Swift usually does) and stopping at the first failed unwrap 
> would make sense. I wouldn’t necessarily say it’s intuitive but I don’t think 
> it’s really less intuitive than the current chaining behaviour. 

I think it gets confusing when you have multiple levels of nested expressions, 
eg

foo(bar(x?)) + y?

Slava

> 
> Jared
> 
>> On 11 Dec 2017, at 19:28, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> This topic has been discussed at least two and maybe more times in the 
>> past.. It’s hard for me to post links at the moment, but it should be 
>> possible to find on Google.
>> 
>> One major challenge to this idea, for which no satisfactory answer has been 
>> achieved after all these years, is the following issue:
>> 
>> f(g()?, h()?, i(), j()?)?
>> 
>> If g() evaluates to nil, is h() called or not? How about i(), which is not 
>> failable? Since any function or property access can have side effects, in 
>> what order are the arguments evaluated, and how does one reason about this 
>> code flow?
>> 
>> To my mind, in the absence of an intuitive answer to the above—which does 
>> not appear to be possible—this idea is not feasible.
>> On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution 
>> > wrote:
>> 
>> > 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 thoughts on this particular syntax (ignoring 3. 
>> > momentarily)? Hopefully others in this thread can share their views too.
>> 
>> Chaining methods is linear, while nesting fills a similar purpose when we 
>> use function calls. This of course affects the way existing Swift code is 
>> written, but that is something we have to live with if we want to use 
>> familiar syntax patterns. However, I think we have to consider this 
>> difference in this case, since the syntax becomes more convoluted. Your 
>> suggestion is definitely not as easy to read as the optional chaining 
>> syntax, and maybe it can't be.
>> 
>> > As for how common I’d expect it to be, it’s something I’ve run into myself 
>> > a few times. Again, I hope members of this list can give their view on if 
>> > this would be useful to them.
>> 
>> I don't have any real examples, but I certainly think that I have run into 
>> it, so I'm quite open to solving the problem. For me, it is probably only a 
>> matter of finding a syntax that is acceptable.
>> 
>> > 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ 
>> > has never been available as a postfix operator. Perhaps I’m missing your 
>> > point, could you demonstrate where it is allowed?
>> 
>> I did not expect that you would be able to answer that, it was more a 
>> question directed to people who are more connected to the inner workings of 
>> the parsing of Swift than I am. It is not allowed, but the error message is 
>> not the one I expect, something that gives me a hint that it does have some 
>> meaning early in the parsing.
>> 
>> /Magnus
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional Argument Chaining

[Félix Cloutier via swift-evolution]

You talk about flatMap without giving an example. The readme isn't that bad 
with it, IMO:

if let readme = String(contentsOfFile: "README.md").flatMap(Markdown) {
// use contents here
}

That doesn't work when you need multiple optional parameters. In my own 
experience, that hasn't been a huge problem, though.

Félix

> Le 11 déc. 2017 à 08:30, Jared Khan via swift-evolution 
>  a écrit :
> 
> Hi all,
> 
> 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 
> nil if any link in that chain breaks. I propose we introduce syntax to allow 
> similar chaining when passing optional valued parameters to functions that 
> expect that parameter to be non-optional.
> 
> The example below is taken from a project I'm working on at the moment:
> 
> 
> // Current
> let readme: Markdown?
> if let rawMarkdown = String(contentsOfFile: "README.md") {
>   readme = Markdown(string: rawMarkdown)
> } else {
>   readme = nil
> }
> In this example we want to perform an operation, the initialisation of a 
> 'Markdown' type, with our raw text if it exists and get nil otherwise. This 
> is rather verbose
> 
> I propose the following syntax for an alternative:
> 
> 
> // Proposed alternative
> let readme = Markdown(string: String(contentsOfFile: "README.md")?)
> 
> The ? is familiar in its use for optional chaining.
> 
> This would act like syntactic sugar for the flatMap method on Optional. For 
> example:
> 
> (where `john` is of a `Person` type with a property `address: Address?`)
> // func getZipCode(fromAddress address: Address) -> ZipCode
> getZipCode(fromAddress: john.address?)
> 
> // Would be equivalent to…
> john.address.flatMap {
>   getZipCode($0)
> }
> An example with multiple parameters:
> 
> // func getPostageEstimate(source: Address, destination: Address, weight: 
> Double) -> Int
> getPostageEstimate(source: john.address?, destination: alice.address?, 
> weight: 2.0)
> 
> // Equivalent to
> john.address.flatMap { freshVar1 in
>   alice.address.flatMap { freshVar2 in
>   getPostageEstimate(source: freshVar1, destination: freshVar2, 
> weight: 2.0)
>   }
> }
> 
> // Or equally:
> {
>   guard let freshVar1 = john.address,
>   let freshVar2 = alice.address else {
>   return nil
>   }
> 
>   return getPostageEstimate(source: freshVar1, destination: freshVar2, 
> weight: 2.0)
> }()
> This would only be allowed when the parameter doesn’t already accept 
> Optionals and when the chained value is in fact an optional. We’d want to 
> consider emitting at least the following errors/warnings in the given 
> scenarios:
> 
> 
> let result = myFunc(3?)
> // error: cannot use optional chaining on non-optional value of type 'Int'
> 
> // func myFunc2(x: String?) -> String
> let result = myFunc2(x: john.address?)
> // error: cannot use optional argument chaining on argument of optional type
> let result = myFunc(nil?)
> // warning: optional argument chaining with nil literal always results in nil
> 
> Seeking your thoughts on this idea, the specific syntax, and more use case 
> examples.
> 
> Best,
> 
> Jared
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

[Ben Rimmington via swift-evolution]

When claiming a staged account, can the username be changed?
e.g. Having the same "@username" on GitHub and Swift Forums.

Will people with multiple accounts be able to merge them?


Names with non-Latin characters are not imported correctly:

e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] constant var

[Inder Kumar Rathore . via swift-evolution]

Hi All,
Today I was writing code and faced a situation where I need to make a
instance variable a const i.e. it shouldn't accept new values from anywhere
but the problem is that I want it's content to be mutable.

e.g.

class MyClass {
  var myDict = [String : String]()
}


I want above variable to be constant and if I make it like below

class MyClass {
  let myDict = [String : String]()
}

Then I cann't add key/value in the myDict like

   self.myDict["name"] = "Rathore"


I know swift and couldn't find anything related to this.

Can anybody help me?


If there is no such method of doing it then I would suggest to either use a
syntax like

class MyClass {
  const var myDict = [String : String]()
}

I'm not using *final *here since that make a var not overridable.



-- 
Best regards,
Inder Kumar Rathore
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

[Ben Rimmington via swift-evolution]

[Forum] merging multiple staged accounts


[Forum] importing names with non-Latin characters


-- Ben

> On 12 Dec 2017, at 06:41, Ben Rimmington wrote:
> 
> When claiming a staged account, can the username be changed?
> e.g. Having the same "@username" on GitHub and Swift Forums.
> 
> Will people with multiple accounts be able to merge them?
> 
> 
> Names with non-Latin characters are not imported correctly:
> 
> e.g. StringTransform("Any-Latin; Latin-ASCII; Any-Title")
> 
> -- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] constant var

[Rafael Guerreiro via swift-evolution]

You actually need a class to wrap the dictionary.
That’s because dictionaries are struct, with copy-on-write.

With a class, you’ll be able to have it mutable, in a let declaration.
On Mon, Dec 11, 2017 at 11:34 PM Inder Kumar Rathore . via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi All,
> Today I was writing code and faced a situation where I need to make a
> instance variable a const i.e. it shouldn't accept new values from anywhere
> but the problem is that I want it's content to be mutable.
>
> e.g.
>
> class MyClass {
>   var myDict = [String : String]()
> }
>
>
> I want above variable to be constant and if I make it like below
>
> class MyClass {
>   let myDict = [String : String]()
> }
>
> Then I cann't add key/value in the myDict like
>
>self.myDict["name"] = "Rathore"
>
>
> I know swift and couldn't find anything related to this.
>
> Can anybody help me?
>
>
> If there is no such method of doing it then I would suggest to either use
> a syntax like
>
> class MyClass {
>   const var myDict = [String : String]()
> }
>
> I'm not using *final *here since that make a var not overridable.
>
>
>
> --
> Best regards,
> Inder Kumar Rathore
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution