[Pitch] Make `default` function parameter values more transparent

I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).

I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:

/// De-initialize the `count` `Pointee`s starting at `self`, returning
/// their memory to an uninitialized state.
///
/// - Precondition: The `Pointee`s at `self..<self + count` are
/// initialized.
///
/// - Postcondition: The memory is uninitialized.
public func deinitialize(count: Int = default)
To cut it short:

Could we make default function parameter values more transparent in Swift 3?
Why are default parameter values translated to default rather than the actual value?
Can we make this independent from docs?

···

--
Adrian Zubarev
Sent with Airmail

I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).

I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:

/// De-initialize the `count` `Pointee`s starting at `self`, returning
/// their memory to an uninitialized state.
///
/// - Precondition: The `Pointee`s at `self..<self + count` are
/// initialized.
///
/// - Postcondition: The memory is uninitialized.
public func deinitialize(count: Int = default)
To cut it short:

Could we make default function parameter values more transparent in Swift 3?
Why are default parameter values translated to default rather than the actual value?

I guess that in some cases you don't want the default value to be known, or is irrelevant. Most importantly, it can be a more complex expression - e.g. creating an object and calling something on it:

private let mySecretNumber = 0x999
public func deinitialize(count: Int = NSProcessInfo().processorCount + mySecretNumber)

And that's a pretty example, it can get much nastier. Since mySecretNumber is private, it definitely cannot be exposed.

···

On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Can we make this independent from docs?

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

As Charlie says the default value may not actually be public.

There was a thread a while ago about allowing defaults to be defined in protocols, but I don’t think it ever got made into a proposal; this would be useful however in cases where you want a consistent, known default. Either that or you need the option of declaring a default value as public perhaps?

···

On 11 Jun 2016, at 14:35, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).

I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:

/// De-initialize the `count` `Pointee`s starting at `self`, returning
/// their memory to an uninitialized state.
///
/// - Precondition: The `Pointee`s at `self..<self + count` are
/// initialized.
///
/// - Postcondition: The memory is uninitialized.
public func deinitialize(count: Int = default)
To cut it short:

Could we make default function parameter values more transparent in Swift 3?
Why are default parameter values translated to default rather than the actual value?
Can we make this independent from docs?

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

I'm not sure what enhancing defaults would look like, especially for protocols. Are you suggesting if there's a protocol like:

protocol A {
   func requiredFunction(a, b, c) -> T
}

that you could then extend

extension A {
    func requiredFunction(a, b = somedefault, c) -> T;
}

as a declaration without an implementation?

-- E

···

On Jun 13, 2016, at 2:17 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

As Charlie says the default value may not actually be public.

There was a thread a while ago about allowing defaults to be defined in protocols, but I don’t think it ever got made into a proposal; this would be useful however in cases where you want a consistent, known default. Either that or you need the option of declaring a default value as public perhaps?

On 11 Jun 2016, at 14:35, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).

I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:

/// De-initialize the `count` `Pointee`s starting at `self`, returning
/// their memory to an uninitialized state.
///
/// - Precondition: The `Pointee`s at `self..<self + count` are
/// initialized.
///
/// - Postcondition: The memory is uninitialized.
public func deinitialize(count: Int = default)
To cut it short:

Could we make default function parameter values more transparent in Swift 3?
Why are default parameter values translated to default rather than the actual value?
Can we make this independent from docs?

True but I think we should consider some consitency for apis, I'd prefer docs independent transparency but I could live with good documentation (guidline update?).

···

--
Adrian Zubarev
Sent with Airmail

Am 13. Juni 2016 um 06:27:22, Charlie Monroe (charlie@charliemonroe.net(mailto:charlie@charliemonroe.net)) schrieb:

> On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote:
>
> I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).
>
>
> I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:
>
> /// De-initialize the `count` `Pointee`s starting at `self`, returning /// their memory to an uninitialized state. /// /// - Precondition: The `Pointee`s at `self..<self + count` are /// initialized. /// /// - Postcondition: The memory is uninitialized. public func deinitialize(count: Int = default)
>
> To cut it short:
>
> Could we make default function parameter values more transparent in Swift 3?
> Why are default parameter values translated to default rather than the actual value?
>
>
>

I guess that in some cases you don't want the default value to be known, or is irrelevant. Most importantly, it can be a more complex expression - e.g. creating an object and calling something on it:

private let mySecretNumber = 0x999
public func deinitialize(count: Int = NSProcessInfo().processorCount + mySecretNumber)

And that's a pretty example, it can get much nastier. Since mySecretNumber is private, it definitely cannot be exposed.

> Can we make this independent from docs?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution

That was my reaction as well, but this change is already in the pipeline, according to Apple’s published plans.

Presumably, once this goes through, it will no longer be possible to use a secret number as a default value.

Charles

···

On Jun 12, 2016, at 11:27 PM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).

I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:

/// De-initialize the `count` `Pointee`s starting at `self`, returning
/// their memory to an uninitialized state.
///
/// - Precondition: The `Pointee`s at `self..<self + count` are
/// initialized.
///
/// - Postcondition: The memory is uninitialized.
public func deinitialize(count: Int = default)
To cut it short:

Could we make default function parameter values more transparent in Swift 3?
Why are default parameter values translated to default rather than the actual value?

I guess that in some cases you don't want the default value to be known, or is irrelevant. Most importantly, it can be a more complex expression - e.g. creating an object and calling something on it:

private let mySecretNumber = 0x999
public func deinitialize(count: Int = NSProcessInfo().processorCount + mySecretNumber)

And that's a pretty example, it can get much nastier. Since mySecretNumber is private, it definitely cannot be exposed.

I would understand the java notion of default implementation directly in the protocol for optional methods, but default values across any implementation ever dies not ring a bell as something I ever wished I had.

Regards
LM
(From mobile)

···

On Jun 13, 2016, at 4:52 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

I'm not sure what enhancing defaults would look like, especially for protocols. Are you suggesting if there's a protocol like:

protocol A {
   func requiredFunction(a, b, c) -> T
}

that you could then extend

extension A {
    func requiredFunction(a, b = somedefault, c) -> T;
}

as a declaration without an implementation?

-- E

On Jun 13, 2016, at 2:17 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

As Charlie says the default value may not actually be public.

There was a thread a while ago about allowing defaults to be defined in protocols, but I don’t think it ever got made into a proposal; this would be useful however in cases where you want a consistent, known default. Either that or you need the option of declaring a default value as public perhaps?

On 11 Jun 2016, at 14:35, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I just installed the current Swift 3 snapshot to play around with it (last from may crashed my Xcode all the time).

I wanted to re-build a small project with (currently implemented) Swift 3 changes. Basically I had to look up on GitHub what the default value for deinitialize(count:) function was for UnsafeMutablePointer, just because Xcode and the docs can’t tell me that:

/// De-initialize the `count` `Pointee`s starting at `self`, returning
/// their memory to an uninitialized state.
///
/// - Precondition: The `Pointee`s at `self..<self + count` are
/// initialized.
///
/// - Postcondition: The memory is uninitialized.
public func deinitialize(count: Int = default)
To cut it short:

Could we make default function parameter values more transparent in Swift 3?
Why are default parameter values translated to default rather than the actual value?
Can we make this independent from docs?

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

I was thinking more that we could allow a fixed default on protocols where it makes sense to, for example:

  protocol A {
    func requiredFunction(a, b = somedefault, c) -> T
  }

In this case all conforming types need to specify the same default for absolute consistency, but this may be a bit divergent from what the OP actually wants, I just mentioned it because it seemed a bit similar. This would come with the caveat that most of the time you don’t want to do this (as it could unnecessarily limit implementations) but it would mean that you know what the default is for every single conforming type.

Specifically for the OP though an attribute might make more sense, like:

  struct Foo : A {
    func requiredFunction(a, b = @public somedefault, c) -> T { … }
  }

Here the default for b is explicitly declared as public, so would be exposed via documentation automatically; this would require that it isn’t derived from anything hidden (allowing this to be checked) and wouldn’t involve exposing every default value implicitly just for being on a public method as the OP was questioning.

Just some options anyway, since I don’t think exposing all defaults automatically is really viable.

···

On 13 Jun 2016, at 15:52, Erica Sadun <erica@ericasadun.com> wrote:

I'm not sure what enhancing defaults would look like, especially for protocols. Are you suggesting if there's a protocol like:

protocol A {
   func requiredFunction(a, b, c) -> T
}

that you could then extend

extension A {
    func requiredFunction(a, b = somedefault, c) -> T;
}

as a declaration without an implementation?