Hi, Isn't it odd to have both main.swift and Main.swift for a project?
Considering Swift 3 provides source breaking changes, can this be still worth an side effort to pursue with the compiler team as advised by Kostiantyn in the bug report? If so, how'd I approach them regarding this? Isn't the Swift Package Manager a (new) tool in handling Swift code? Is this really the case where a minor change/addition to a convention is so difficult that it shouldn't be done? Can't Xcode support only either Main.swift or main.swift in the future? The bug report is linked here https://bugs.swift.org/browse/SR-1379 > On May 2, 2016, at 09:34, Jordan Rose <jordan_r...@apple.com> wrote: > > [+swift-dev, bcc swift-users] I’d be fine with supporting “Main.swift”. The > one downside is that it could change behavior for existing projects relying > on “Main.swift” being a library file, and that might mean it’s not worth > making a change. > > Jordan > > >> On May 1, 2016, at 23:34, Kostiantyn Koval via swift-users >> <swift-us...@swift.org> wrote: >> >> Hi there, >> >> main is common used naming for executables that contains main function. It’s >> required by Swift compiler and Swift Package Manager can’t do anything about >> that. >> If you create a simple command line tool in Xcode, it will create main.swift >> file. If you try to rename it, it will feil. >> I think this is correct behaviour. >> If you still think that Swift should support Main.swift with upper case >> letter, than it should be discussed with compiler team. >> >> - Kostiantyn >> >> > Hi there, >> > >> > This is what happened as I was trying out the Swift Package Manager for >> > another project similar to the one shown below: >> > >> > ~ $ mkdir example >> > ~ $ cd example/ >> > example $ touch Package.swift >> > example $ mkdir Sources >> > >> > example $ vi Sources/Example.swift >> > example $ cat Sources/Example.swift >> > func printOther() { >> > print("other") >> > } >> > >> > example $ vi Sources/Main.swift >> > example $ cat Sources/Main.swift >> > print("Hello World") >> > printOther() >> > >> > >> > example $ swift build >> > Compile Swift Module 'example' (2 sources) >> > /PATH/example/Sources/Main.swift:1:1: error: expressions are not allowed >> > at the top level >> > print("Hello World") >> > ^ >> > /PATH/example/Sources/Main.swift:2:1: error: expressions are not allowed >> > at the top level >> > printOther() >> > ^ >> > /PATH/example/Sources/Main.swift:1:1: error: expressions are not allowed >> > at the top level >> > print("Hello World") >> > ^ >> > /PATH/example/Sources/Main.swift:2:1: error: expressions are not allowed >> > at the top level >> > printOther() >> > ^ >> > <unknown>:0: error: build had 1 command failures >> > error: exit(1): /PATH-SWIFT/usr/bin/swift-build-tool -f >> > /PATH/example/.build/debug.yaml >> > >> > >> > example $ mv Sources/Main.swift Sources/main.swift >> > example $ swift build >> > Compile Swift Module 'example' (2 sources) >> > Linking .build/debug/example >> > example $ .build/debug/example >> > Hello World >> > other >> > example $ >> > >> > >> > I had to renameMain.swifttomain.swift. Is there a design decision on why >> > the filename for the main swift file has to be lowercase or is this a bug? >> > >> > If it’s a design decision, why are directory names forsource files allowed >> > to have variations likeSources,Source,srcandsrcsas >> > statedhere(https://github.com/apple/swift-package-manager/blob/master/Documentation/SourceLayouts.md#other-rules)but >> > not the main swift file? >> > >> > I’d be ok if onlyMain.swiftandmain.swiftare allowed since other files in >> > theSourcesdirectory are commonly UpperCamelCasedue to the Type naming >> > conventions >> > e.g.example-package-playingcard/Sources(https://github.com/apple/example-package-playingcard/tree/master/Sources). >> > >> > Or maybe I’m just being pedantic? >> > >> > p.s. evenPackage.swiftis capitalized and notpackage.swift >> > >> > $ swift --version >> > Swift version 3.0-dev (LLVM 752e1430fc, Clang 1e6cba3ce3, Swift 56052cfe61) >> > Target: x86_64-unknown-linux-gnu >> > >> > >> > >> > >> > >> _______________________________________________ >> swift-users mailing list >> swift-us...@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
