This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
So
f: ( input: Int) -> Void
becomes
f: ( input: Int) -> Nothing
Instead of saying “f takes an Int and returns a Void” I read this as “f takes an Int and returns nothing”.
I’ve been using f:(input: Int) -> () because it’s easier to explain than Void to non-experienced programmers. Experienced programmers have no problem with Void. But Void seems to be something we’re using just because we have for a while - like x++ and C-style for loops.
This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
So
f: ( input: Int) -> Void
becomes
f: ( input: Int) -> Nothing
Instead of saying “f takes an Int and returns a Void” I read this as “f takes an Int and returns nothing”.
I’ve been using f:(input: Int) -> () because it’s easier to explain than Void to non-experienced programmers. Experienced programmers have no problem with Void. But Void seems to be something we’re using just because we have for a while - like x++ and C-style for loops.
Quite frankly, I think the ship has long sailed for renaming Void.
···
On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:
Sent from my iPad
> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution < > swift-evolution@swift.org> wrote:
>
> This may be a silly question - given that one of Swift’s design
principles is to be a language for new programmers and for APIs to read
like English phrases, should we replace the typealias of Void for the
return type () with Nothing.
>
> So
>
> f: ( input: Int) -> Void
>
> becomes
>
> f: ( input: Int) -> Nothing
>
> Instead of saying “f takes an Int and returns a Void” I read this as “f
takes an Int and returns nothing”.
>
> I’ve been using f:(input: Int) -> () because it’s easier to explain than
Void to non-experienced programmers. Experienced programmers have no
problem with Void. But Void seems to be something we’re using just because
we have for a while - like x++ and C-style for loops.
>
> Best,
>
> Daniel
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Quite frankly, I think the ship has long sailed for renaming Void.
Agree. I’m not advocating change, just stating things that should be considered if anyone wants to propose it.
···
On Jul 21, 2016, at 11:59 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPad
> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
>
> So
>
> f: ( input: Int) -> Void
>
> becomes
>
> f: ( input: Int) -> Nothing
>
> Instead of saying “f takes an Int and returns a Void” I read this as “f takes an Int and returns nothing”.
>
> I’ve been using f:(input: Int) -> () because it’s easier to explain than Void to non-experienced programmers. Experienced programmers have no problem with Void. But Void seems to be something we’re using just because we have for a while - like x++ and C-style for loops.
>
> Best,
>
> Daniel
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
I did note that Nothing had been considered for another purpose and rejected so I didn’t think it would cause confusion.
I understand folks who advocate another name such as Unit but don’t feel that would help newcomers. Unit doesn’t seem to be more intuitive for them than Void.
Chris’ note addressed my misconception that a goal of Swift was that it could be a good first or learning language. I apologize for drawing that conclusion from (perhaps misreading) articles about Playgrounds that mentioned Swift as being designed so that it was a ideal for children and new programmers. The articles may have meant that the environment was designed for that purpose not the language.
Although my examples were in stand-alone functions, I was really thinking about functions that are passed as argument to other functions.
Given the response, there doesn’t seem to be a reason for me to draw up a proposal.
Thank you for the quick feedback,
Best,
Daniel
···
On Jul 21, 2016, at 1:19 PM, Matthew Johnson <matthew@anandabits.com> wrote:
On Jul 21, 2016, at 11:59 AM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
Quite frankly, I think the ship has long sailed for renaming Void.
Agree. I’m not advocating change, just stating things that should be considered if anyone wants to propose it.
On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Sent from my iPad
> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
>
> So
>
> f: ( input: Int) -> Void
>
> becomes
>
> f: ( input: Int) -> Nothing
>
> Instead of saying “f takes an Int and returns a Void” I read this as “f takes an Int and returns nothing”.
>
> I’ve been using f:(input: Int) -> () because it’s easier to explain than Void to non-experienced programmers. Experienced programmers have no problem with Void. But Void seems to be something we’re using just because we have for a while - like x++ and C-style for loops.
>
> Best,
>
> Daniel
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
There's a difference between returning a void type and returning nothing.
An instance of Void is a catch-all 'something' which conforms to no
protocols, which can be quite useful with generic types.
···
On Thu, Jul 21, 2016 at 5:59 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:
Quite frankly, I think the ship has long sailed for renaming Void.
On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
Sent from my iPad
> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> This may be a silly question - given that one of Swift’s design
principles is to be a language for new programmers and for APIs to read
like English phrases, should we replace the typealias of Void for the
return type () with Nothing.
>
> So
>
> f: ( input: Int) -> Void
>
> becomes
>
> f: ( input: Int) -> Nothing
>
> Instead of saying “f takes an Int and returns a Void” I read this as “f
takes an Int and returns nothing”.
>
> I’ve been using f:(input: Int) -> () because it’s easier to explain
than Void to non-experienced programmers. Experienced programmers have no
problem with Void. But Void seems to be something we’re using just because
we have for a while - like x++ and C-style for loops.
>
> Best,
>
> Daniel
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
I think on that issue the favourite for replacing @noreturn is Never or NoReturn, rather than Nothing (since @noreturn doesn't return nothing, it doesn't return in the first place), so Nothing is actually okay in that regard.
I wouldn't mind the change of name, as void to me suggests something like a yawning abyss, which implies a substantive gap, rather than an actual absence of something, whereas Nothing is a bit clearer. That said I've never had any real trouble with Void, but can see Nothing being a tad easier to teach.
It's also not necessarily a very disruptive change, as many people don't write -> Void and just omit it, though personally I prefer to always write it out explicitly.
···
On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
I think on that issue the favourite for replacing @noreturn is Never or NoReturn, rather than Nothing (since @noreturn doesn't return nothing, it doesn't return in the first place), so Nothing is actually okay in that regard.
Yes, Never won that debate. But Nothing was considered and does imply “bottom type” to many people. That is why I don’t think it is a good choice here.
I wouldn't mind the change of name, as void to me suggests something like a yawning abyss, which implies a substantive gap, rather than an actual absence of something, whereas Nothing is a bit clearer. That said I've never had any real trouble with Void, but can see Nothing being a tad easier to teach.
It's also not necessarily a very disruptive change, as many people don't write -> Void and just omit it, though personally I prefer to always write it out explicitly.
Agree. I’m neutral on changing it. I just think Nothing is the wrong name. I would advocate Unit if we’re going to change it. Both Unit and Void have precedence in other languages. The precedence for Nothing in other languages is “bottom type” which means it is going to be a confusing choice.
···
On Jul 21, 2016, at 12:51 PM, Haravikk <swift-evolution@haravikk.me> wrote:
On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
Please clarify this. I said that Swift was not designed to mock English grammar. It is absolutely intended to be a good teaching language, and I never said otherwise.
-Chris
···
On Jul 21, 2016, at 3:02 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
Chris’ note addressed my misconception that a goal of Swift was that it could be a good first or learning language.
On Jul 21, 2016, at 6:29 PM, Chris Lattner <clattner@apple.com> wrote:
On Jul 21, 2016, at 3:02 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
Chris’ note addressed my misconception that a goal of Swift was that it could be a good first or learning language.
Please clarify this. I said that Swift was not designed to mock English grammar. It is absolutely intended to be a good teaching language, and I never said otherwise.
This may be a silly question - given that one of Swift’s design principles is to be a language for new programmers and for APIs to read like English phrases, should we replace the typealias of Void for the return type () with Nothing.
I think on that issue the favourite for replacing @noreturn is Never or NoReturn, rather than Nothing (since @noreturn doesn't return nothing, it doesn't return in the first place), so Nothing is actually okay in that regard.
TS 2.0 adopted 'never'
···
On Jul 21, 2016, at 7:51 PM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
I wouldn't mind the change of name, as void to me suggests something like a yawning abyss, which implies a substantive gap, rather than an actual absence of something, whereas Nothing is a bit clearer. That said I've never had any real trouble with Void, but can see Nothing being a tad easier to teach.
It's also not necessarily a very disruptive change, as many people don't write -> Void and just omit it, though personally I prefer to always write it out explicitly.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I think there might be some confusion since the Swift API Design Guidelines session at WWDC 2016 mentions:
“One of the principles of this particular API Design Guidelines is that we really want the use sites to read grammatically.”
and continues with a number of examples.
and the current Swift API Design Guidelines state:
“Prefer method and function names that make use sites form grammatical English phrases.”.
So there has been strong guidance to prefer Swift APIs that read like English grammar at the call site.
But I don’t think there has been any guidance to make API declarations read like English grammar.
But Chris just wrote:
I said that Swift was not designed to mock English grammar
My understanding is that:
- It is preferable for method and function names to form grammatical English phrases at the call site — but not absolutely necessary if something that breaks this guideline provides more clarity at the call site.
- There is no guidance that API declarations are expected to read grammatically
Is my understanding correct?
Thanks,
James
···
———————
James Dempsey
dempsey@mac.com
On Jul 21, 2016, at 3:29 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 21, 2016, at 3:02 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
Chris’ note addressed my misconception that a goal of Swift was that it could be a good first or learning language.
Please clarify this. I said that Swift was not designed to mock English grammar. It is absolutely intended to be a good teaching language, and I never said otherwise.
I think there might be some confusion since the Swift API Design Guidelines session at WWDC 2016 mentions:
“One of the principles of this particular API Design Guidelines is that we really want the use sites to read grammatically.”
and continues with a number of examples.
and the current Swift API Design Guidelines state:
“Prefer method and function names that make use sites form grammatical English phrases.”.
So there has been strong guidance to prefer Swift APIs that read like English grammar at the call site.
But I don’t think there has been any guidance to make API declarations read like English grammar.
But Chris just wrote:
I said that Swift was not designed to mock English grammar
We shouldn’t conflate language design and API design. It’s true that a programming language’s builtin keywords make up part of all APIs at the end of the day. But the language has a different set of priorities. Language designer (most of the time) have more syntax to worry about than API designers. The importance of term of art, succinctness, read-like-natural-language-ness…have different weights compared to APIs (not saying one way or another).
My understanding is that:
- It is preferable for method and function names to form grammatical English phrases at the call site — but not absolutely necessary if something that breaks this guideline provides more clarity at the call site.
- There is no guidance that API declarations are expected to read grammatically
You said it in the first point: clarity at point of use is preferred, not necessarily at the point of declaration.
···
On Jul 22, 2016, at 2:38 PM, James Dempsey via swift-evolution <swift-evolution@swift.org> wrote:
Is my understanding correct?
Thanks,
James
———————
James Dempsey
dempsey@mac.com
On Jul 21, 2016, at 3:29 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 21, 2016, at 3:02 PM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:
Chris’ note addressed my misconception that a goal of Swift was that it could be a good first or learning language.
Please clarify this. I said that Swift was not designed to mock English grammar. It is absolutely intended to be a good teaching language, and I never said otherwise.
English is the dominating language of the world. Yes, its a context sensitive language whose limits will be reached and will be replaced by a new languages that recursively enumerable but we cant deviate from the foundational teachings that English has allowed us to perceive reality from its grammar.