[swift-evolution] Straw Poll. Re: Method cascading (was Re: Request for Discussion: Setup closures)

[Joe Groff]

> On Dec 7, 2015, at 8:22 AM, Sean Heber via swift-evolution <swift-evolution at swift.org> wrote:
> 
> What I like about the statement “with” variant (obviously biased here) is that it could also, I think, adequately solve the common if-let unwrapping situation that many find cumbersome if “let/var” isn’t assumed to be required to be a part of the construct.
> 
> If you used “with” with an optional, it could just skip the entire block if the value was nil. For cases where you only have things to do when the optional is non-nil, and being nil is perfectly okay, this would allow you to pretty naturally write that code without using forced unwrapping or creating a shadowed unwrapped variable.
> 
> let foo: MyObject? = nil
> with foo {
>  .thing = 42
>  .otherThing(“meaning of life”)
> }

Note that using leading '.' is syntactically ambiguous. The above already parses as `.thing = 42.otherThing("meaning of life")` (or would, if we didn't already ban statements from starting with '.' for exactly this reason).

-Joe

> In this case, the entire inner block could just be skipped over since foo is nil. So, I think, not only can this construct address things like initialization chains, I think it can also address the unwrapping tedium too.
> 
> It would not change or shadow anything outside the scope of the block, however. If MyObject had a failable initializer, then this would still mean that “bar” is typed MyObject? even if init fails - so it doesn’t unwrap it outside of the block’s scope, but it provides a nice way to safely use an optional without manually unwrapping it:
> 
> with let bar = MyObject() {
>  .thing = 42
>  .otherThing(“meaning of life”)
> }
> 
> And we could go farther here and end up with something like this:
> 
> if with bar {
>  <does stuff to bar>
> } else {
>  <bar was nil>
> }
> <bar is still typed as optional here>
> 
> l8r
> Sean
> 
> 
>> On Dec 7, 2015, at 9:41 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Following this weekend's discussions, I'm running a quick poll. It's short. 
>> 
>> FEAGTURE WRITE-UP:  https://gist.github.com/erica/eb32feb22ba99629285a
>> POLL HERE:  https://www.surveymonkey.com/r/KFYD5RT
>> 
>> I want to gauge interest in method cascading so I don't push a proposal without reasonably broad support.
>> 
>> Thank you -- Erica
>> 
>>> On Dec 7, 2015, at 12:08 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Nice to see that most points from my wishlist 
>>> are already discussed here ;-)
>>> I didn't even know this feature got a name, but it
>>> would be great for working with graphic contexts
>>> and some orher tasks.
>>> 
>>> But I would prefer another approach over a new keyword:
>>> context.{
>>> moveTo(x: 23, y: 42)
>>> lineTo(x: 0, y: 0)
>>> }
>>> is quite intuitive to me, and I can't see any downsides so far
>>> (first thought was just braces without the dot, but that
>>> could clash when you want to use the syntax with the
>>> return value of a function, which could have a trailing closure).
>>> 
>>> Something similiar could be archieved by dropping
>>> void as default return value in favour of self...
>>> 
>>> 
>>> Von meinem iPhone gesendet
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution