The current workaround is to add an overload that calls the "main" version:
> class Foo {
> // version 1
> func foo() {
> print(5)
> }
>
> // version 2
> func foo() {
> foo(5)
> }
>
> func foo(value: Int) {
> print(value)
> }
> }
How would you say that your solution compares?
Félix
> Le 28 déc. 2015 à 11:11:57, Matthew Johnson via swift-evolution
> <[email protected]> a écrit :
>
> I've had an idea floating around in my mind for a couple weeks now and would
> like to find out what others think about it.
>
> The basic idea is really simple. It introduces an `@option` parameter
> attribute. Parameters with this attribute would behave like parameters with
> a default value at the call site, however they would not actually have a
> default value. Instead, the argument seen in the body would be an optional
> of the type of the parameter value.
>
> func foo(@option value: Int) {
> // value has type Int? in the body of the function
> let valueToUse = value ?? 42
> }
>
> At first glance it probably seems like this is of no value. Why not just
> declare `value: Int? = nil`. Obviously it must bring something to the table
> to be worth considering.
>
> This idea first occurred to me while thinking about flexible memberwise
> initialization. One of the use cases I have had in mind while writing that
> proposal is a theoretical Swift version of UIKit that exposes all of its
> appearance properties as memberwise initialization parameters with defaults
> rather than just initializing the members to a default value. Obviously this
> could lead to a very large stack frame that isn't really necessary. Using
> the `@option` approach we can avoid the unnecessarily large stack frame.
>
> Instead of always passing a value for every parameter the compiler would use
> a single dynamic data structure containing the values of all `@option`
> arguments provided at the call site. The layout of the data structure would
> be an implementation detail of the language and would be part of the ABI. It
> would contain a header of some kind indicating which parameters were actually
> provided with arguments at the call site and any additional information
> necessary to recover the value. In the body of the function, references to
> the parameter value would be replaced with a lookup into the data structure
> which returned an optional value of the type of the parameter.
>
> Perhaps the most interesting thing about `@option` is that careful design of
> the implementation might allow for `@option` parameters to be added or
> removed from a function without breaking ABI compatibility:
>
> 1. When new parameters are added, existing callers will simply never provide
> arguments and the implementation will see a nil optional value.
> 2. When parameters are removed, existing clients will continue to provide
> them and the data structure will still be populated with them. The
> implmentation will simply never look for the value. The function will behave
> as if the parameter was still specified in the signature and simply not used.
> The client would receive a compiler warning when compiling agains the newer
> SDK but everything would continue to work without issue until they did so.
>
> If this is possible `@option` parameters would enable more robust evolution
> for functions containing parameters that may be omitted or have default
> values.
>
> Another benefit of `@option` is that it provides better encapsulation of
> default values because they do not appear in function and method signatures.
> My understanding of the planned mechanism for default arguments is that any
> changes to default parameter values will not be visible to clients until they
> recompile against the new version of the library. If this is the case
> `@option` would also provide additional control to library authors who may
> wish to modify the default behavior of their implementation without breaking
> ABI.
>
> Lastly, but potentially useful benefit of `@option` is that default argument
> values do not allow a function to distinguish between the case when a caller
> explicitly provides a value that happens to be the same as the default and
> the case when no argument was provided. `@option` provides this information
> to the body of the function.
>
> Finally, an interesting observation: changing a parameter from having a
> default value to `@option` or vice versa would break ABI but would be
> source-compatible.
>
> I am very interested to hear whether others think this idea is worth pursuing
> further or not.
>
> Matthew
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
