[swift-evolution] [Pre-pitch] Conditional default arguments
Tony Allevato
tony.allevato at gmail.com
Mon Nov 27 16:20:40 CST 2017
On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson <matthew at anandabits.com>
wrote:
> On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Really like Tony’s suggestion, much cleaner than yet another annotation
> rammed into the signature. Also the idea of a static factory that could
> accept previously initialized arguments would be very powerful.
>
>
> It is syntactically cleaner at the site of the function declaration for
> sure. Wouldn’t you agree that it is semantically less clear though? Both
> are important, but which is more important? If not semantics, why not?
>
> It’s also worth noting that it would be more verbose in at least some use
> cases (when a declaration such as `defaultConfiguration()` is used in the
> conditional default expression and is not otherwise necessary).
>
>
> -- Howard.
>
> On 26 Nov 2017, at 9:25 am, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Sat, Nov 25, 2017 at 1:16 PM Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> On Sat, Nov 25, 2017 at 15:06 Matthew Johnson <matthew at anandabits.com>
>> wrote:
>>
>>> On Nov 25, 2017, at 1:28 PM, Tony Allevato via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> On Fri, Nov 24, 2017 at 7:18 PM Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>
>>> It's kludgy, but we could have something like:
>>>>
>>>> ```
>>>> @defaultArgument(configuration = (), where R.Configuration == Void)
>>>> @defaultArgument(actionHandler = { _ in }, where R.Action == Never)
>>>> func makeResource(with configuration: R.Configuration, actionHandler:
>>>> @escaping (R.Action) -> Void) -> R { ... }
>>>> ```
>>>>
>>>> I don't like that we'd be setting a default argument on something
>>>> lexically before even encountering it in the declaration, but it's
>>>> serviceable.
>>>>
>>>
>>>
>>> What if we could take advantage of the fact that you can have
>>> non-constant expressions in default arguments? Overload resolution could
>>> already do most of the job—what we need on top of that is a way for the
>>> author to say that “if no overload matches, then it’s not an error—just
>>> don’t have a default argument in that case”. Something like SFINAE in C++,
>>> but more explicit.
>>>
>>> I’m imagining something like this:
>>>
>>> func defaultConfiguration() -> Void {
>>> return ()
>>> }
>>> func defaultActionHandler() -> (Never) -> Void {
>>> return { _ in }
>>> }
>>> struct ResourceDescription<R: Resource> {
>>> func makeResource(
>>> with configuration: R.Configuration *=?* defaultConfiguration(),
>>> actionHandler: @escaping (R.Action) -> Void *=?* defaultActionHandler()
>>> ) -> R {
>>> // create a resource using the provided configuration
>>> // connect the action handler
>>> // return the resource
>>> }
>>> }
>>>
>>> The main difference here is the strawman =? syntax, which would
>>> indicate that “the default argument exists if there is a way the RHS can be
>>> satisfied for some instances of the generic arguments; otherwise, there is
>>> no default”, instead of today’s behavior where it would be an error. There
>>> could be multiple overloads of defaultConfiguration and
>>> defaultActionHandler (even ones that are themselves generic) and it
>>> would do the right thing when there are matches and when there aren’t.
>>>
>>> I like this approach because it mostly takes advantage of existing
>>> language features and is fairly lightweight in terms of how it’s expressed
>>> in code compared to regular default arguments—we’d just need to design the
>>> new operator and type-checker logic around it.
>>>
>>> This is an interesting approach. One advantage to something in this
>>> direction is that it could support defining different defaults for the same
>>> argument under different constraints by overloading the default argument
>>> factories on their return type.
>>>
>>> One concern I have is that it doesn’t allows us to clearly define under
>>> which constraints a default argument is available. I suspect this might be
>>> problematic especially for public interfaces where source compatibility is
>>> a concern.
>>>
>>
>> It's certainly an interesting idea but it would suggest that the
>> constraints under which a default argument is available can change at
>> runtime. I'm concerned, like you, that this is difficult to reason about.
>> It is still unclear to me how widespread the underlying issue is that
>> requires conditional default arguments, but the conversation thus far has
>> been about compile-time constraints and Tony's design seems to envision
>> much more than that.
>>
>
> This runtime/reasoning problem *already exists* today with default
> arguments, because you can write something like this:
>
> struct Foo {
> static var defaultExponent = 2.0
>
> func raise(_ x: Double, to exponent: Double = defaultExponent) {
> print(pow(x, exponent))
> }
> }
> Foo().raise(4) // "16.0"Foo.defaultExponent = 3.0Foo().raise(4) // "64.0"
>
> Swift lets you write a default value expression that references static
> (but not instance) vars of the enclosing type, as well as anything else
> that’s visible from that expression’s scope. Should people do this?
> Probably not, for the reasons that you described.
>
> But the point is that my example is no more harmful or difficult to reason
> about than default arguments in the language today. My proposed solution *in
> no way* changes the runtime behavior of default argument expressions. I’m
> not envisioning anything more than what default arguments can already do
> except for adding a way to choose different default factories (or choose
> none without error) based on the *static* types of the generic arguments
> that are bound at a particular call site.
>
>
>
>> I think I prefer Xiaodi’s suggestion for that reason. His approach could
>>> also support multiple defaults for the same parameter as long as the
>>> constraints are not allowed to overlap (overlapping constraints would
>>> result in ambiguity similar to ambiguous overload resolution) or an
>>> explicit argument is required if they do.
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> On Fri, Nov 24, 2017 at 8:36 PM, T.J. Usiyan via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> I am all for this. are many types where there is an obvious 'zero' or
>>>>> 'default' value and the ability to express "use that when possible" without
>>>>> an overload is welcome.
>>>>>
>>>>>
>>>>> The best thing that I can think of right now, in terms of syntax, is
>>>>> actually using @overload
>>>>>
>>>>> ```
>>>>> struct ResourceDescription<R: Resource> {
>>>>>
>>>>> func makeResource(with configuration: R.Configuration,
>>>>> actionHandler: @escaping (R.Action) -> Void) -> R
>>>>> @overload(R.Configuration == Void) func makeResource(actionHandler:
>>>>> @escaping (R.Action) -> Void) -> R
>>>>> @overload(R.Action == Never) func makeResource(with configuration:
>>>>> R.Configuration) -> R
>>>>> {
>>>>> // create a resource using the provided configuration
>>>>> // connect the action handler
>>>>> // return the resource
>>>>> }
>>>>> }
>>>>> ```
>>>>>
>>>>>
>>>>> This isn't great though…
>>>>>
>>>>> On Fri, Nov 24, 2017 at 6:11 PM, Matthew Johnson via swift-evolution <
>>>>> swift-evolution at swift.org> wrote:
>>>>>
>>>>>> As mentioned in my prior message, I currently have a PR open to
>>>>>> update the generics manifesto (
>>>>>> https://github.com/apple/swift/pull/13012). I removed one topic
>>>>>> from that update at Doug Gregor’s request that it be discussed on the list
>>>>>> first.
>>>>>>
>>>>>> The idea is to add the ability to make default arguments conditional
>>>>>> (i.e. depend on generic constraints). It is currently possible to emulate
>>>>>> conditional default arguments using an overload set. This is verbose,
>>>>>> especially when several arguments are involved. Here is an example use
>>>>>> case using the overload method to emulate this feature:
>>>>>>
>>>>>> ```swift
>>>>>> protocol Resource {
>>>>>> associatedtype Configuration
>>>>>> associatedtype Action
>>>>>> }
>>>>>> struct ResourceDescription<R: Resource> {
>>>>>> func makeResource(with configuration: R.Configuration,
>>>>>> actionHandler: @escaping (R.Action) -> Void) -> R {
>>>>>> // create a resource using the provided configuration
>>>>>> // connect the action handler
>>>>>> // return the resource
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> extension ResourceDescription where R.Configuration == Void {
>>>>>> func makeResource(actionHandler: @escaping (R.Action) -> Void) -> R
>>>>>> {
>>>>>> return makeResource(with: (), actionHandler: actionHandler)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> extension ResourceDescription where R.Action == Never {
>>>>>> func makeResource(with configuration: R.Configuration) -> R {
>>>>>> return makeResource(with: configuration, actionHandler: { _ in })
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> extension ResourceDescription where R.Configuration == Void, R.Action
>>>>>> == Never {
>>>>>> func makeResource() -> R {
>>>>>> return makeResource(with: (), actionHandler: { _ in })
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> ```
>>>>>>
>>>>>> Adding language support for defining these more directly would
>>>>>> eliminate a lot of boilerplate and reduce the need for overloads. Doug
>>>>>> mentioned that it may also help simplify associated type inference (
>>>>>> https://github.com/apple/swift/pull/13012#discussion_r152124535).
>>>>>>
>>>>>> The reason that I call this a pre-pitch and one reason Doug requested
>>>>>> it be discussed on list is that I haven’t thought of a good way to express
>>>>>> this syntactically. I am interested in hearing general feedback on the
>>>>>> idea. I am also looking for syntax suggestions.
>>>>>>
>>>>>> Matthew
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171127/98fd8577/attachment.html>
More information about the swift-evolution
mailing list