[swift-evolution] Optional Argument Chaining

Hi all, We probably don't need additional syntax to achieve this. I just wrote a library which allows you to `(pass?.aLongOptionalChaining()?.to ?< aFunctionTakingNonOptionalValues(:))?.ThenDoSomethingElse()` with `?>` operator. The multiple parameters example: (john.address, alice.address,

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 and Timeline for Discourse Transition

> On Dec 12, 2017, at 3:28 PM, Alejandro Martinez wrote: > > Yes that's what I was suggesting. > My view is that different kind of conversations would happen in a > "help" vs. "announcements" category. Some people may be interested in > being up to date with the more

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

Yes that's what I was suggesting. My view is that different kind of conversations would happen in a "help" vs. "announcements" category. Some people may be interested in being up to date with the more experienced users, announcements of new projects or putting together efforts towards a lib or

Re: [swift-evolution] Optional Argument Chaining

That’s actually the cool part of merging optional func infix ? with the discussed problem. If you think how we could represent optional func in pure swift only with some sugar (and also the ability to write var function(label:label:) which we’ll get at some point) then we could do this:

Re: [swift-evolution] Optional Argument Chaining

In addition to being unspecific, how would you access an optional closure? Since trailing operators can’t be separated with whitespace, how do you differentiate two trailing “?” from a “??” operator? i.e. let a:Int? = ... let b:Int? = ... let someFunction:((Int, Int)->(Int))? = ... let c =

Re: [swift-evolution] Optional Argument Chaining

I propose that we do not add a suffix ? to the arguments because it does not really signal that the whole function may return an optional value. This is especially not convenient in a nested scenario like mentioned by others in previous posts. Instead we should reuse the inifix ? on functions,

Re: [swift-evolution] Optional Argument Chaining

Even this small example I think this is still a little fiddly. If we add another required parameter to the Markdown initializer: let readme = String(contentsOfFile: “README.md”).flatMap { Markdown(string: $0, flavor: .github) } this starts to feel a little inside-out and crufty to me.

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

> On Dec 12, 2017, at 1:36 PM, Alejandro Martinez via swift-evolution > wrote: > > On Tue, Dec 12, 2017 at 4:15 PM, Kelvin Ma > wrote: >> >> >> On Tue, Dec 12, 2017 at 5:31 AM, Alejandro Martinez via

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

On Tue, Dec 12, 2017 at 4:15 PM, Kelvin Ma wrote: > > > On Tue, Dec 12, 2017 at 5:31 AM, Alejandro Martinez via swift-evolution > wrote: >> >> This sounds great! >> Specially the new structure, it reminds me of the Rust forums. I just >> have one

Re: [swift-evolution] Optional Argument Chaining

I’d agree with that. That’s consistent with the “left-to-right and short-circuit at first failure” approach. > On 12 Dec 2017, at 15:33, Yuta Koshizawa wrote: > > I think evaluating them in the same way as `try` calls is consistent. > > ``` > f(g()?, h()?, i(), j()?)? > //

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

> On 12 Dec 2017, at 19:27, C. Keith Ray via swift-evolution > wrote: > > in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 > > > there is this statement: > > "For this reason,

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

in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 there is this statement: "For this reason, the compiler only permits conformance of this protocol on the original type definition, not extensions" and this example: extension JSON : DynamicMemberLookupProtocol {

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

> On Dec 10, 2017, at 13:01, Chris Lattner via swift-evolution > wrote: > >>> 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 >>>

Re: [swift-evolution] constant var

> On Dec 11, 2017, at 11:34 PM, Inder Kumar Rathore . via swift-evolution > 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

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

On Tue, Dec 12, 2017 at 5:31 AM, Alejandro Martinez via swift-evolution < swift-evolution@swift.org> wrote: > This sounds great! > Specially the new structure, it reminds me of the Rust forums. I just > have one question, is the Using Swift category expected to be the one > where the community

Re: [swift-evolution] constant var

If I understand correctly, you want to be able to modify myDict from within MyClass, but not from outside it. In that case, you’re looking for private(set). class MyClass { private(set) var myDict = [String : String]() } -BJ > On Dec 12, 2017, at 12:34 AM, Inder Kumar Rathore . via

Re: [swift-evolution] Optional Argument Chaining

I think evaluating them in the same way as `try` calls is consistent. ``` f(g()?, h()?, i(), j()?)? // like try f(try g(), try h(), i(), try j()) ``` ``` foo(bar(x()?)) + y()? // like foo(bar(try x())) + (try y()) ``` -- Yuta 2017-12-12 7:42 GMT+09:00 Slava Pestov via swift-evolution

Re: [swift-evolution] Optional Argument Chaining

In my opinion, simple left to right evaluation where it short circuits on the first failure is the simplest. But I don’t think it matters that much as long as we have a consistent way to define it, and explain it. It is nice to have forward transfer from other features, but sometimes we just

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

This sounds great! Specially the new structure, it reminds me of the Rust forums. I just have one question, is the Using Swift category expected to be the one where the community posts project announcements for new libraries or similar stuff? I remember a recent thread where some people wanted to

Re: [swift-evolution] Optional Argument Chaining

I think it might be a good idea to reuse optional function syntax in this case. I don’t think it would even break existing code with the rule I described in my previous post. I mean, in the end the result of the whole function becomes optional (only if it was non-optional before, or it simply

Re: [swift-evolution] Optional Argument Chaining

To me the short syntax should be a ‘macro’ expansion (syntax sugar only), therefore option 1 in Nick’s example. I choose the syntax sugar option because it is easy to explain. -- Howard. > On 12 Dec 2017, at 7:03 pm, Nick Keets via swift-evolution > wrote: > >

Re: [swift-evolution] constant var

here’s the problem. if your type is an inline type (ie a struct or an enum), modifying a member of your object is really modifying part of the entire variable. so, declaring the variable as let makes no sense. if your type is an indirect type (a class), modifying a member of your object is really

Re: [swift-evolution] constant var

Ugliness is preferable to the alternative of impossibility because what you are trying to do and the semantics of the type you are trying to do it with are irreconcilably and mutually exclusive. > On Dec 12, 2017, at 12:00 AM, Inder Kumar Rathore . via swift-evolution >

Re: [swift-evolution] Optional Argument Chaining

On Tue, Dec 12, 2017 at 12:42 AM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > > I think it gets confusing when you have multiple levels of nested > expressions, eg > > foo(bar(x?)) + y? > > Slava > I'm not sure we need to optimize much for complicated nested examples,

Re: [swift-evolution] constant var

Nice idea but I think the code will look ugly On Tue, Dec 12, 2017 at 1:28 PM, Rafael Guerreiro wrote: > 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,