Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Eric Summers via swift-evolution]

Yeah.  There are so many pitfalls to passing parameters implicitly.  It only 
works for exceptions because the function is annotated with throws.

Eric

> On Nov 2, 2017, at 10:05 PM, Xiaodi Wu  wrote:
> 
> I think the use case is legitimate, but I'm uncomfortable with the proposed 
> solution. Firstly, because for the proposed use case it's not a "default" 
> parameter in that it's not overridable: you can't actually pass another 
> argument. Secondly, because you wouldn't want the two parameters of an infix 
> operator function, or the single parameter of a non-infix operator function, 
> to allow a default value (that totally gums up the distinction between 
> prefix, infix, and postfix operators). I agree with Eric that the use case 
> feels like it calls for a "macro-like" solution.
> 
> On Thu, Nov 2, 2017 at 7:50 PM, Eric Summers via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I think this makes more sense as part of a hygienic macro system.  These 
> “hidden” parameters could be made available to standard functions using some 
> sort of convention to exclude them from autocompletion.
> 
> Eric
> 
> 
>> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I like this idea as it's presented here, for the debugging/logging reasons 
>> that you stated.
>> 
>> Should we tighten the shackles a little be to validate that *only* the 
>> special #file/#line/#function directives can be permitted for these extra 
>> parameters? I'm struggling to think of a case where we would want to allow 
>> something else, since there's no way to provide the values for them in a 
>> standard call.
>> 
>> 
>> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Hi SE,
>> 
>> As I’ve been using my own custom operators like “?!”, “!!”, or operators 
>> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file 
>> and #line where the operators are used to make debugging their use a lot 
>> easier.
>> 
>> For example, given something the unwrap-or-die operator 
>> (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
>>  
>> <https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md>),
>>  you’d want to capture the #file and #line so you could pass it on to the 
>> underlying call to fatalError().
>> 
>> Or, if you’re using a custom bind operator and something goes wrong, it’d be 
>> great to be able to capture the file and line where the operator is used so 
>> you can quickly triage the bug in your code.
>> 
>> Unfortunately, Swift has the hard limit the the implementations of unary 
>> operators may have one-and-only-one parameter, and that binary operators may 
>> only have two parameters.
>> 
>> I’d like to propose a very minor change to Swift, whereby operator 
>> implementations may have more than their one or two parameters, provided 
>> that all subsequent parameters come with a default value. This would make it 
>> trivial to add in #file, #line, #function, etc to your operator 
>> implementations, which you can then capture for your own purposes.
>> 
>> An implementation of this change, with passing tests, can be found here: 
>> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>>  
>> <https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697>
>> 
>> Dave
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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] Extending trailing closure sugar similar to property accessors

[Eric Summers via swift-evolution]

That makes sense.  I thought there may be a parsing trick involved with the way 
property accessors are designed.  

> On Nov 2, 2017, at 9:00 PM, Slava Pestov  wrote:
> 
> This is not possible in general, since we want the parser to be able to parse 
> code without having knowledge of declarations and their types (which might 
> come from other modules). Overloaded declarations complicate this further.
> 
> I agree that the existing property syntax already has this issue, which is 
> unfortunate, but we should not introduce features that make the problem worse.
> 
> Slava

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

Re: [swift-evolution] Extending trailing closure sugar similar to property accessors

[Eric Summers via swift-evolution]

A similar problem exists with property accessors.  Although you could call 
those keywords, they will probably be extensible when behaviors are introduced 
leading to a similar situation.  It can be worked around by making the priority 
of argument labels higher then function calls within the curly brackets.

Eric

> On Nov 2, 2017, at 8:51 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 2, 2017, at 4:04 PM, Eric Summers via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> // A sugar similar to property accessors for multiple trailing closures:
>> foobar(a: 1, b: 2) {
>> completionBlock { x, y in
>> // ...
>> }
>> failureBlock { i, j in
>> // ...
>> }
>> }
> 
> This syntax is ambiguous. Are you passing in two trailing closures to 
> foobar(), or a single trailing closure, inside which you call two top-level 
> functions, completionBlock and failureBlock?
> 
> Slava
> 
> ___
> 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: Allow operators to have parameters with default values

[Eric Summers via swift-evolution]

I think this makes more sense as part of a hygienic macro system.  These 
“hidden” parameters could be made available to standard functions using some 
sort of convention to exclude them from autocompletion.

Eric

> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> I like this idea as it's presented here, for the debugging/logging reasons 
> that you stated.
> 
> Should we tighten the shackles a little be to validate that *only* the 
> special #file/#line/#function directives can be permitted for these extra 
> parameters? I'm struggling to think of a case where we would want to allow 
> something else, since there's no way to provide the values for them in a 
> standard call.
> 
> 
> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Hi SE,
> 
> As I’ve been using my own custom operators like “?!”, “!!”, or operators 
> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file 
> and #line where the operators are used to make debugging their use a lot 
> easier.
> 
> For example, given something the unwrap-or-die operator 
> (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
>  
> ),
>  you’d want to capture the #file and #line so you could pass it on to the 
> underlying call to fatalError().
> 
> Or, if you’re using a custom bind operator and something goes wrong, it’d be 
> great to be able to capture the file and line where the operator is used so 
> you can quickly triage the bug in your code.
> 
> Unfortunately, Swift has the hard limit the the implementations of unary 
> operators may have one-and-only-one parameter, and that binary operators may 
> only have two parameters.
> 
> I’d like to propose a very minor change to Swift, whereby operator 
> implementations may have more than their one or two parameters, provided that 
> all subsequent parameters come with a default value. This would make it 
> trivial to add in #file, #line, #function, etc to your operator 
> implementations, which you can then capture for your own purposes.
> 
> An implementation of this change, with passing tests, can be found here: 
> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>  
> 
> 
> Dave
> ___
> 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] Extending trailing closure sugar similar to property accessors

[Eric Summers via swift-evolution]

I’d like to hear thoughts on extending trailing closure syntax to avoid long 
inline closures.  A significant benefit to adopting this sugar would be to 
clarify indentation style for long inline closures.  I apologize if this has 
been brought up before, but I couldn’t find anything searching the list.

There is a lot of discussion about hacking around the issues with inline 
closures.  Here are a few examples:
https://www.natashatherobot.com/swift-trailing-closure-syntax/
https://owensd.io/2015/02/20/handling-multiple-closure-parameters/
https://bugs.swift.org/browse/SR-1199
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html

I think a syntax similar to property accessors to allow multiple trailing 
closures could make these scenarios feel swifty.  Property accessors already 
have a "get" specialization that is similar to the current trailing closures 
syntax, so in theory this could be a backwards compatible extension. 

func foobar(a: Int, b: Int, completionBlock: ((Int, Int) -> Void), 
failureBlock: ((Int, Int) -> Void) {
// ...
}

// Current syntax:
foobar(a: 1, b: 2,
completionBlock: { x, y in
// ...
},
failureBlock: { i, j in
// ...
})

// A sugar similar to property accessors for multiple trailing closures:
foobar(a: 1, b: 2) {
completionBlock { x, y in
// ...
}
failureBlock { i, j in
// ...
}
}

Best,
Eric

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Eric Summers via swift-evolution]

What about:
public
private
private(module) // instead of internal
private(file) or private(test)

Eric

Sent from my iPhone

> On Mar 14, 2016, at 5:41 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> What color is your bikeshed?
> 
> I don't suppose you'd consider swapping private and internal (since the 
> opposite of public is private, and internal means inside)?
> 
> Anyway, there's fileScoped (or filescoped), access(file) (which has the 
> option of being used for access with module and global), 
> filedelimited, filefixed, filebounded, filebound, filerestricted.
> 
> You may want constructing phrases around bounding, restrictions, access, 
> limitations, visibility, and local.
> 
> -- E
> 
> 
> 
> 
>> On Mar 14, 2016, at 6:18 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Per Doug’s email, the core team agrees we should make a change here, but 
>> would like some bikeshedding to happen on the replacement name for private.
>> 
>> To summarize the place we’d like to end up:
>> 
>> - “public” -> symbol visible outside the current module.
>> - “internal” -> symbol visible within the current module.
>> - unknown -> symbol visible within the current file.
>> - “private” -> symbol visible within the current declaration (class, 
>> extension, etc).
>> 
>> The rationale here is that this aligns Swift with common art seen in other 
>> languages, and that many people using private today don’t *want* visibility 
>> out of their current declaration.  It also encourages “extension oriented 
>> programming”, at least it will when some of the other restrictions on 
>> extensions are lifted.  We discussed dropping the third one entirely, but 
>> think it *is* a useful and important level of access control, and when/if we 
>> ever get the ability to write unit tests inside of the file that defines the 
>> functionality, they will be a nicer solution to @testable.
>> 
>> The thing we need to know is what the spelling should be for the third one.  
>> Off hand, perhaps:
>> 
>> fileprivate
>> private(file)
>> internal(file)
>> fileaccessible
>> etc
>> 
>> Some other thoughts on the choice: 
>> - this will be a declaration modifier, so it will not “burn” a keyword.
>> - if will be a uniquely Swift thing, so there is virtue in it being a 
>> googlable keyword.
>> 
>> Thoughts appreciated.
>> 
>> -Chris
>> 
>> ___
>> 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