Swift Package Manager and main.swift

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 rename Main.swift to main.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 for source files allowed to have variations like Sources, Source, src and srcs as stated here <https://github.com/apple/swift-package-manager/blob/master/Documentation/SourceLayouts.md#other-rules&gt; but not the main swift file?

I’d be ok if only Main.swift and main.swift are allowed since other files in the Sources directory are commonly UpperCamelCase due to the Type naming conventions e.g. example-package-playingcard/Sources <https://github.com/apple/example-package-playingcard/tree/master/Sources&gt;\.

Or maybe I’m just being pedantic?

p.s. even Package.swift is capitalized and not package.swift

$ swift --version
Swift version 3.0-dev (LLVM 752e1430fc, Clang 1e6cba3ce3, Swift 56052cfe61)
Target: x86_64-unknown-linux-gnu

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-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-users@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-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

···

On May 2, 2016, at 09:34, Jordan Rose <jordan_rose@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-users@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-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

My concern is not about people who have both main.swift and Main.swift; it's people who have libraries/frameworks (no main.swift) where one of the source files happens to be named Main.swift. This isn't likely, but it is possible.

We're certainly not going to drop "main.swift" in favor of "Main.swift", so the question would just be if we wanted to add "Main.swift". And I don't think we want different rules for Xcode and the package manager, especially not when the package manager can generate simple Xcode projects.

Jordan

···

On May 2, 2016, at 10:09, Natthan Leong <kar.joon@icloud.com> wrote:

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
[SR-1379] Swift Package Manager and main.swift · Issue #5451 · apple/swift-package-manager · GitHub

On May 2, 2016, at 09:34, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@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-users@swift.org <mailto:swift-users@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-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

Maybe that's why we should introduce the addition of 'Main.swift' before the Swift Package Manager (and Swift 3.0) hits stable?

I've never requested to drop 'main.swift'. I merely prefer the additional support for 'Main.swift'. Library/Frameworks should not have 'Main.swift' imho as it leads to further confusion.

If the compiler and Xcode team find this too difficult to add support for and not for any other reasons, I'd be okay with sticking with 'main.swift'. Just find it odd for reasons specified throughout this email thread.

···

On May 2, 2016, at 10:20, Jordan Rose <jordan_rose@apple.com> wrote:

My concern is not about people who have both main.swift and Main.swift; it's people who have libraries/frameworks (no main.swift) where one of the source files happens to be named Main.swift. This isn't likely, but it is possible.

We're certainly not going to drop "main.swift" in favor of "Main.swift", so the question would just be if we wanted to add "Main.swift". And I don't think we want different rules for Xcode and the package manager, especially not when the package manager can generate simple Xcode projects.

Jordan

On May 2, 2016, at 10:09, Natthan Leong <kar.joon@icloud.com> wrote:

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
[SR-1379] Swift Package Manager and main.swift · Issue #5451 · apple/swift-package-manager · GitHub

On May 2, 2016, at 09:34, Jordan Rose <jordan_rose@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-users@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-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

SwiftPM is case-insensitive about its conventions in general, so I consider this a bug.

It’s possible it’ll break existing projects, but well, existing projects are breaking constantly at this time due to language changes, so this is just another thing.

···

On May 2, 2016, at 10:33 AM, Natthan Leong via swift-dev <swift-dev@swift.org> wrote:

Maybe that's why we should introduce the addition of 'Main.swift' before the Swift Package Manager (and Swift 3.0) hits stable?

I've never requested to drop 'main.swift'. I merely prefer the additional support for 'Main.swift'. Library/Frameworks should not have 'Main.swift' imho as it leads to further confusion.

If the compiler and Xcode team find this too difficult to add support for and not for any other reasons, I'd be okay with sticking with 'main.swift'. Just find it odd for reasons specified throughout this email thread.

On May 2, 2016, at 10:20, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

My concern is not about people who have both main.swift and Main.swift; it's people who have libraries/frameworks (no main.swift) where one of the source files happens to be named Main.swift. This isn't likely, but it is possible.

We're certainly not going to drop "main.swift" in favor of "Main.swift", so the question would just be if we wanted to add "Main.swift". And I don't think we want different rules for Xcode and the package manager, especially not when the package manager can generate simple Xcode projects.

Jordan

On May 2, 2016, at 10:09, Natthan Leong <kar.joon@icloud.com <mailto:kar.joon@icloud.com>> wrote:

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
[SR-1379] Swift Package Manager and main.swift · Issue #5451 · apple/swift-package-manager · GitHub

On May 2, 2016, at 09:34, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@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-users@swift.org <mailto:swift-users@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-users@swift.org <mailto:swift-users@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

If it were just SwiftPM that would be fine, but I'd like someone to sign off on it being okay to (potentially) break existing Xcode projects as well.

(This needs Xcode- and compiler-side changes as well, unfortunately. It's not just the package manager.)

Jordan

···

On May 2, 2016, at 10:52, Max Howell <max.howell@apple.com> wrote:

SwiftPM is case-insensitive about its conventions in general, so I consider this a bug.

It’s possible it’ll break existing projects, but well, existing projects are breaking constantly at this time due to language changes, so this is just another thing.

On May 2, 2016, at 10:33 AM, Natthan Leong via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Maybe that's why we should introduce the addition of 'Main.swift' before the Swift Package Manager (and Swift 3.0) hits stable?

I've never requested to drop 'main.swift'. I merely prefer the additional support for 'Main.swift'. Library/Frameworks should not have 'Main.swift' imho as it leads to further confusion.

If the compiler and Xcode team find this too difficult to add support for and not for any other reasons, I'd be okay with sticking with 'main.swift'. Just find it odd for reasons specified throughout this email thread.

On May 2, 2016, at 10:20, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

My concern is not about people who have both main.swift and Main.swift; it's people who have libraries/frameworks (no main.swift) where one of the source files happens to be named Main.swift. This isn't likely, but it is possible.

We're certainly not going to drop "main.swift" in favor of "Main.swift", so the question would just be if we wanted to add "Main.swift". And I don't think we want different rules for Xcode and the package manager, especially not when the package manager can generate simple Xcode projects.

Jordan

On May 2, 2016, at 10:09, Natthan Leong <kar.joon@icloud.com <mailto:kar.joon@icloud.com>> wrote:

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
[SR-1379] Swift Package Manager and main.swift · Issue #5451 · apple/swift-package-manager · GitHub

On May 2, 2016, at 09:34, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@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-users@swift.org <mailto:swift-users@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-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

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

My preference here is that SwiftPM treat "Main.swift" as an error (and suggest "main.swift"), for now. If we agree the compiler should support it as a synonym for main.swift, then we can remove that.

- Daniel

···

On May 2, 2016, at 10:55 AM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

If it were just SwiftPM that would be fine, but I'd like someone to sign off on it being okay to (potentially) break existing Xcode projects as well.

(This needs Xcode- and compiler-side changes as well, unfortunately. It's not just the package manager.)

Jordan

On May 2, 2016, at 10:52, Max Howell <max.howell@apple.com <mailto:max.howell@apple.com>> wrote:

SwiftPM is case-insensitive about its conventions in general, so I consider this a bug.

It’s possible it’ll break existing projects, but well, existing projects are breaking constantly at this time due to language changes, so this is just another thing.

On May 2, 2016, at 10:33 AM, Natthan Leong via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Maybe that's why we should introduce the addition of 'Main.swift' before the Swift Package Manager (and Swift 3.0) hits stable?

I've never requested to drop 'main.swift'. I merely prefer the additional support for 'Main.swift'. Library/Frameworks should not have 'Main.swift' imho as it leads to further confusion.

If the compiler and Xcode team find this too difficult to add support for and not for any other reasons, I'd be okay with sticking with 'main.swift'. Just find it odd for reasons specified throughout this email thread.

On May 2, 2016, at 10:20, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

My concern is not about people who have both main.swift and Main.swift; it's people who have libraries/frameworks (no main.swift) where one of the source files happens to be named Main.swift. This isn't likely, but it is possible.

We're certainly not going to drop "main.swift" in favor of "Main.swift", so the question would just be if we wanted to add "Main.swift". And I don't think we want different rules for Xcode and the package manager, especially not when the package manager can generate simple Xcode projects.

Jordan

On May 2, 2016, at 10:09, Natthan Leong <kar.joon@icloud.com <mailto:kar.joon@icloud.com>> wrote:

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
[SR-1379] Swift Package Manager and main.swift · Issue #5451 · apple/swift-package-manager · GitHub

On May 2, 2016, at 09:34, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@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-users@swift.org <mailto:swift-users@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-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

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

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