Exit Codes From Main

etcwilde · 2022-11-30T06:20:36.772Z

That's kind of the direction I've been leaning, yeah.

benrimmington · 2022-11-30T07:09:02.900Z

etcwilde:

Do we want to allow a throwing main function to return an explicit status code, or is the current behavior sufficient?

Could the ArgumentParser.ExitCode type be added to the standard library?
Then the @main type, or a top-level script, could throw a standard or custom exit code.

stevapple · 2022-11-30T11:57:40.706Z

I feel like this should not be an error type, but a protocol. Tool authors can bind error types to custom exit state.

However, if we really make it a protocol, we should also clarify that library authors are not suggested to do so as this could possibly lead to collisions with other libraries.

Joe_Groff · 2022-11-30T17:00:12.374Z

jrose:

I’m being a bit facetious here, but really I think we should just add exit to System and call it a day. I would hate for someone to prefer @main over top-level code because they wanted to return EXIT_FAILURE. (I realize that’s a matter of opinion, but it’s also something the project seems to care about, cf. SE-0343 Concurrency in Top-Level Code. EDIT: also from you, heh.)

That's my feeling as well. There isn't really anything concretely special about returning from main from any contemporary OS's perspective; in practice, main is going to return into crt stub code that's equivalent to passing the return value to exit(3) to tear down the process anyway.

etcwilde · 2022-11-30T17:17:42.050Z

@jrose

EDIT: also from you, heh.

I noticed that too. That proposal was an extension of the language to bring concurrency to top-level, after the @main version had it though.

Is this something we would add to Swift if C didn’t exist? I’ll note that even though C’s main returns int , and exit takes an int argument, exit codes aren’t actually int or Int32

In a purely Swift world, we'd likely use Int. @Joe_Groff has also brought this up offline. Given that different shells and environments truncate the result differently I'm thinking the overload could be something like main() -> Int and then we quietly truncate it to a CInt for the implicit @main function so that crtend.o handles the final result properly.

I think we should just add exit to System and call it a day.

That would work too. That would effectively end up being a call to the C exit function, wouldn't it?

@benrimmington

Could the ArgumentParser.ExitCode type be added to the standard library?
Then the @main type, or a top-level script, could throw a standard or custom exit code.

We could probably do something like this from a throwing main. I think there are some challenges to that in terms of cost and complexity. We would need to inspect the thing being thrown, ensure it conforms at some point to ExitCode, and fish out the value to return. In the case that an error is thrown, but isn't a ExitCode, what would we want to do?

Maybe it's the C in me talking, but exit(15) or return 15 reads nicer than throw ExitCode(15).

@stevapple

I feel like this should not be an error type, but a protocol. Tool authors can bind error types to custom exit state.

You're going to need to provide an example. I'm not sure what you mean.

@main struct MainType {
  static func main() -> Int {
    guard openFile() else {
      return 1
    }
    guard doStuff() else {
      return 2
    }
   return 0
}

How would something like this with protocols?

taylorswift · 2022-11-30T17:44:32.161Z

etcwilde:

There is one point that I've glossed over. Throwing main functions today will return with 1 if the main function threw an error, 0 otherwise.

Do we want to allow a throwing main function to return an explicit status code, or is the current behavior sufficient?

i like the current convention where throwing from a top level function makes the program return 1. i don’t think there’s much value in allowing for non-boolean return codes, since that reduces portability.

one problem with top level errors is they always print a full stack trace when the program exists, and sometimes i want to print something more user-friendly. if there were a way to customize the error output, i would not need to return exit codes from main.

blangmuir · 2022-11-30T17:49:30.072Z

jrose:

I think we should just add exit to System and call it a day. I would hate for someone to prefer @main over top-level code because they wanted to return EXIT_FAILURE.

This is how I'm leaning as well. Exit statuses other than simple success/failure are likely to either be for inter-process communication with processes you own, where you also want to be able to exec/waitpid/etc., or for communication with processes you don't own, which is going to be platform-specific. This feels like a good case for swift-system. Another advantage is you could easily add a way to call _Exit and maybe even atexit as well. Incidentally, exit is on the swift-system api roadmap.

Failing that, I also kind of like the idea of adding an error protocol with exit status.

Joe_Groff · 2022-11-30T17:53:55.213Z

blangmuir:

Failing that, I also kind of like the idea of adding an error protocol with exit status.

We could potentially extend the existing Error protocol with a new defaulted requirement:

protocol Error {
  var processExitCode: Int
}

extension Error {
  var processExitCode: Int { return 1 }
}

and have it so that errors that propagate from main/top-level code end the process with the error value's processExitCode. I think it'd still be useful to have a standard standalone exit(_:) function too, though.

taylorswift:

one problem with top level errors is they always print a full stack trace when the program exists, and sometimes i want to print something more user-friendly. if there were a way to customize the error output, i would not need to return exit codes from main.

That might also be a useful extension point on Error, we could have a presentTopLevelError() method that defaults to the stack trace but which user errors can override with nicer presentation logic if they want.

Jean-Daniel · 2022-11-30T20:51:11.364Z

Joe_Groff:

in practice, main is going to return into crt stub code that's equivalent to passing the return value to exit(3) to tear down the process anyway.

Not exactly. Returning from main will only terminate the process if there is no remaining detached thread running, unlike calling exit() which will terminate the process immediately.

Joe_Groff · 2022-11-30T21:15:06.556Z

Jean-Daniel:

Not exactly. Returning from main will only terminate the process if there is no remaining detached thread running, unlike calling exit() which will terminate the process immediately.

At least on Apple platforms, main() literally returns into a call to exit(3) inside dyld:

github.com

apple-opensource/dyld/blob/b6b86eb2db14440d373f6f7fd21be4a2bc0da897/src/start_glue.s

/*
 * Copyright (c) 2011 Apple Inc. All rights reserved.
 *
 * @APPLE_LICENSE_HEADER_START@
 * 
 * This file contains Original Code and/or Modifications of Original Code
 * as defined in and that are subject to the Apple Public Source License
 * Version 2.0 (the 'License'). You may not use this file except in
 * compliance with the License. Please obtain a copy of the License at
 * http://www.opensource.apple.com/apsl/ and read it before using this
 * file.
 * 
 * The Original Code and all software distributed under the License are
 * distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
 * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,
 * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
 * Please see the License for the specific language governing rights and
 * limitations under the License.
 *

This file has been truncated. show original

so exit(3) will also leave background threads running while tearing down the main thread (much to our occasional chagrin when a critical runtime data structure accidentally grows a C++ destructor). The C and C++ standards also specify that returning from main must be equivalent to calling exit(3) with the return value. _exit(2) is the underlying system call that summarily kills the process.

Jean-Daniel · 2022-11-30T22:02:35.921Z

I'm stand corrected. Thank you for pointing that out

beccadax · 2022-11-30T23:06:05.342Z

jrose:

I’m being a bit facetious here, but really I think we should just add exit to System and call it a day. I would hate for someone to prefer @main over top-level code because they wanted to return EXIT_FAILURE.

I'd like to suggest a slight variation: add it to Swift.CommandLine, which is currently where you go to retrieve arguments.

extension CommandLine {
    public static func exit(withCode code: Int) -> Never
}

CommandLine.exit(withCode: 42)

ksluder · 2022-11-30T23:10:59.924Z

I like the idea of making it available in the standard library, but CommandLine seems like a strange place for it, given that most users don’t launch GUI apps via the command line yet exit codes are still potentially relevant for GUI apps (e.g. for Mac App Store receipt rejection).

compnerd · 2022-12-01T01:30:33.846Z

I agree returning from main is morally equivalent to calling exit. I do question if being explicit about the exit code is adding clarity to the program or not. I admit that many (all?) non-C languages (at least golang, python, rust off the top of my head) do force you to type out the explicit exit, but I'm not sure it really adds significant value over just returning an exit code from main.

One small problem arises about portability of wrapping exit though. I believe on Windows, ExitProcess and exit behaviour is subtly different in that module destructor ordering is inverted between the two. I really would like to see a singular spelling across the platforms, but with some sort of discriminator to select between the different variants.

etcwilde · 2022-12-01T07:29:00.085Z

I'm mostly fine with an exit function. I don't like the idea of it being in a separate library; having to import and link an extra library just for a return code seems excessive. Especially given that the thing we eventually want to call is already linked into the program without linking an additional library. As @compnerd says, we would need an answer to the exit vs ExitProcess on Windows. I'm not familiar with Windows or these APIs enough to have a meaningful opinion on that front.

I'd still like to understand more of the aversion to having a returning main though. I wouldn't mind extending the pitch further to the full main(args: [String]) -> Int like described in the original proposal for @main: SE-0281 main-attribute.

Is it just that it doesn't generalize to top-level code and other code, or something else?

stevapple · 2022-12-01T07:35:55.992Z

etcwilde:

You're going to need to provide an example. I'm not sure what you mean.

I believe @blangmuir and @Joe_Groff have already explained what I suggested:)

benrimmington · 2022-12-01T09:04:03.367Z

etcwilde:

I'd still like to understand more of the aversion to having a returning main though.

As I understand it, standard C and C++ require one of:

int main();

int main(int argc, char *argv[]);

But they don't need a return 0; statement to indicate success, only a nonzero value to indicate failure. This might be better expressed in Swift as () throws -> Void.

Throwing an error also seems preferable to calling a nonreturning exit(_:), because the former might allow defer statements and other cleanup code to run?

I like Joe's idea of defaulted Error requirements.

Should the default processExitCode be EXIT_FAILURE?
Should presentTopLevelError() have a stderr parameter?

3405691582 · 2022-12-01T14:47:09.530Z

etcwilde:

I don't like the idea of it being in a separate library

You could presumably just use exit from your local C library here, though, if you were writing something that were that low-dependency.

jrose · 2022-12-01T16:39:55.273Z

etcwilde:

I'd still like to understand more of the aversion to having a returning main though.

Personally, I have an aversion to main as a function: it is a lot of extra stuff to learn up front when you are just starting out. Then I have a (mild) aversion to having two equivalent ways to do the same thing if the newer one adds no benefit over the older one.

The big benefit of @main for me was that the main function could come from a library. The benefit of allowing throws is that people didn’t have to learn about exit statuses to handle the 90% case of “my program has failed, it doesn’t matter how”, for either form of the main entry point. Adding a return type to @main doesn’t apply uniformly and doesn’t have the same effect of easing comprehension; learning about “returning from main” isn’t really any simpler than learning about exit (however it ends up being spelled). And because Swift wouldn’t use a name like EXIT_FAILURE, the 90% case of “my program just needs to fail” would either become more verbose (return ExitStatus.failure?) or more baroque (return 1). At least exit(1) or CommandLine.exit(1) becomes a good place to hang documentation.

ksluder · 2022-12-01T16:59:41.718Z

benrimmington:

I like Joe's idea of defaulted Error requirements.

Should the default processExitCode be EXIT_FAILURE?

Maybe we could consider a ProcessExitCodeConvertible protocol, with default implementations that provide sensible mappings on various platforms:

protocol ProcessExitCodeConvertible {
  associatedtype ExitCode // because it’s `int` on POSIX and `UINT` on Windows
  var processExitCode: ExitCode { get }
}

extension Error where Self: ProcessExitCodeConvertible {
  var processExitCode: ExitCode {
    #if WINDOWS
    return UInt(EXIT_FAILURE)
    #else
    return Int(EXIT_FAILURE)
    #endif
  }
}

This still supports throw from top-level code, but requires the developer to think about what that actually means to the system. Throwing @main would of course be enhanced to understand ProcessExitCodeConvertible.