[Pitch] `Never` as the parameter type for function that does not take a parameter

Avi · 2022-03-25T13:55:14.566Z

Developers familiar with functional languages are a distinct minority, and those with a computer science background even more so.

I, for one, would not have known what a Unit type was without explanation, and my undergrad was in CS.

sveinhal · 2022-03-25T14:04:01.844Z

Avi:

Developers familiar with functional languages are a distinct minority, and those with a computer science background even more so.

I, for one, would not have known what a Unit type was without explanation, and my undergrad was in CS.

Sure, but Kotlin also uses Unit and people seem to learn quickly. In fact, many newer languages spell it Unit. Some languages even spell it NUL or struct{}. Python uses None. People seem to cope.

But I digress even more.

David_Catmull · 2022-03-25T14:54:04.121Z

hisekaldma:

This is not how Never and Void work. Never is the uninhabited type , meaning that it has zero possible values. Void is the unit type , meaning it has exactly one possible value. When you use Never , you’re explicitly telling the compiler that this thing is impossible to create.

I think the logic still kind of fits, though. You have a function that takes no parameters. Since it is impossible to pass any parameters to it, you represent that by passing an impossible value.

ksluder · 2022-03-25T14:55:59.068Z

Swift doesn’t model functions as maps from tuples to tuples (anymore), but if it did, functions declared func foo() -> T would map Void to T, not Never to T.

Avi · 2022-03-25T15:16:24.427Z

David_Catmull:

Since it is impossible to pass any parameters to it, you represent that by passing an impossible value.

But "passing an impossible value" already has a definition in Swift: it means "this function is not callable".

Morten_Bek_Ditlevsen · 2022-03-25T15:36:53.694Z

ylorn:

Yes, this is to take advantage of that feature. The way to call a function func bar(_ arg: Never) is bar() , because you cannot create an instance of type Never . So I am suggesting to make a function that takes no parameter an implicit function that takes a Never argument.

It sounds like that would also give you a way to construct a value of type Never. Inside your bar function arg would contain the value that cannot be created. That sounds like it would break the concept of Never.

Joe_Groff · 2022-03-25T16:03:50.320Z

Looking at the motivating example, to avoid syntax artists feeling the need to provide beautification overloads like this:

ylorn:

extension PassthroughSubject where Output == Void {
    func send() {
        self.send(())
    }
}

I would say that, today, you probably just shouldn't do this at all—overloading in Swift is best avoided, because it leads to slow compile times and confusion with generics. But in the fullness of time, this is something that variadic generics would address, since you could define the original protocol as:

struct PassthroughSubject<Output...> {
  func send(_ outputs: Output...)
}

and that would let you call it as send() for no arguments, send(x) for one argument, or send(x, y) for multiple arguments, without micromanaging the overload set.

ksluder · 2022-03-25T16:28:56.606Z

send() and send(_:) have different arities; are they actually overloads?

Joe_Groff · 2022-03-25T16:31:03.306Z

They are and they aren't, since we never fully committed to the "arity and labels are part of the name" model. It's less bad than overloading the same arity/labels, but we still have a lot of places where an unapplied reference like foo.send could resolve to either.

Ben_Cohen · 2022-03-26T03:33:09.481Z

For a concrete example, this is why we don’t have count(where:) in the standard library.

anon9791410 · 2022-03-26T06:45:33.963Z

Joe_Groff:

But in the fullness of time, this is something that variadic generics would address, since you could define the original protocol as:
struct PassthroughSubject<Output...> {
  func send(_ outputs: Output...)
}
and that would let you call it as send() for no arguments, send(x) for one argument, or send(x, y) for multiple arguments, without micromanaging the overload set.

This works well for a verb (i.e. something that historically has () after it) but not for other parts of speech/concepts which, over time, lose their vestigial parens.

There's still one more level of syntactical nothingness to eliminate in those cases, e.g.

extension Result where Success == Void {
  static var success: Self { .success(()) }
}

That's a pain nowadays not only because of having to write the overloads (and deal with any compilation speed hits), but also the inconsistency of the compiler's interpretation of them:

// In most contexts, this `result` is now `.success(())`
let result = Result<_, Error>.success

// And you can get the one that nobody probably wants with explicit typing.
let makeResult = Result<_, Error>.success as (()) -> _

// But here…
extension Result where Success == Void {
  static func voidSuccessContext() {
    // Currently, "Ambiguous use of 'success'", without explicit typing to `Self`.
    let result = success
  }
}

I don't think variadic generics address this?

taylorswift · 2022-03-26T21:13:54.727Z

Joe_Groff:

They are and they aren't, since we never fully committed to the "arity and labels are part of the name" model.

if we aren’t already committed to the “arity and labels are part of the name” model, we should commit to it now, otherwise documentation tooling maintainers are in for a world of pain…

CharlesS · 2022-03-27T22:26:45.303Z

This seems like the sort of pitch that is Never going to get much traction..

(ba dum tiss)

Avi · 2022-03-28T03:12:14.064Z

I feel you may not have passed an argument there.

/groan

sveinhal · 2022-03-28T13:39:02.162Z

David_Catmull:

I think the logic still kind of fits, though. You have a function that takes no parameters. Since it is impossible to pass any parameters to it, you represent that by passing an impossible value.

It may be both useful and make sense. Maybe it also fits some logic. But that's besides the point: It is impossible to use Never for this use case today, because Never already have a difference, non-compatible meaning. Changing its semantics would break the existing semantics.

If this is indeed deemed useful, a new type would need to be invented. Maybe Nothing or something like that. Feel free to suggest and bike shed names.

But Never is never going to get repurposed as proposed.

sveinhal · 2022-03-28T13:43:49.449Z

Joe_Groff:

But in the fullness of time, this is something that variadic generics would address, since you could define the original protocol as:
struct PassthroughSubject<Output...> {
  func send(_ outputs: Output...)
}
and that would let you call it as send() for no arguments, send(x) for one argument, or send(x, y) for multiple arguments, without micromanaging the overload set.

If SE-0347 gets accepted we could perhaps also use default arguments?

struct PassthroughSubject<Output> {
  func send(_ output: Output = ())
}

gwendal.roue · 2022-03-28T14:03:12.473Z

sveinhal:

If SE-0347 gets accepted we could perhaps also use default arguments?
struct PassthroughSubject<Output> {
  func send(_ output: Output = ())
}

That was my initial understanding of SE-0347 initially. Then I changed my mind.

sveinhal · 2022-03-28T14:10:13.217Z

gwendal.roue:

That was my initial understanding of SE-0347 initially. Then I changed my mind .

Changed your mind, in the sense that you consider a function definition like that to be harmful, or at least bad practice? Or you changed your mind, in the sense that you no longer think such a function definition should compile under SE-0347?

gwendal.roue · 2022-03-28T14:17:13.095Z

As I tried to explain in the linked comment, I think that using SE-0347 in order to solve this kind of problem is ill-advised.

To say it in another way: it is not because you find ONE type that is a possible default, that you found THE type that is designed to be the default (the real use case of SE-0347).

In my Void/Ping example, using SE-0347 would have a different outcomes, depending on it is Void, or Ping, that is the first type that is identified as a sensible default. If the evolution of code has Ping appear first, then SE-0347 would use Ping. If the evolution of the same code has Void appear first, then SE-0347 would use Void. To me, this is the sign that SE-0347 was improperly used in this case. Void is not designed to be the default type. It just happens that one developer was first to think that Void would be a good default. This developer was just lucky. In reality he's squatting SE-0347, he's using an undue convenience.

sveinhal · 2022-03-28T14:28:43.132Z

gwendal.roue:

As I tried to explain in the linked comment, I think that using SE-0347 in order to solve this kind of problem is ill-advised.

Thanks. Then I did understand you correctly :-)