Sorry for introducing yet another submodule proposal out of the blue.
I'm a bit surprised at how far-reaching the various submodule proposals floated on this list have been. Directories, access controls, @exported imports... For comparison's sake here's one that is *really* simple and short I wrote today. Best of all: it requires no new access modifier.
I also expect everyone to scream at it because it does not include all the desirable features of a submodule system. At the very least I'll ha…
I have been continuing to follow all of the discussions regarding submodules very closely (including all of the feedback provided for the first draft of this proposal). My thinking on the subject has continued to evolve.
This proposal is very nearly a complete rewrite. The principle of submodules forming strictly hierarchical scopes remains but almost all of the details have changed significantly. It is now extremely lightweight in simple use cases while including the ability to accommodate …
I’ve read through the last couple of Swift (sub)Module proposals put forward, and since my particular use-cases for a sub-module solution seemed to be under-served by them, I’ve decided to write up my thoughts on the matter to prompt discussion.
Perhaps my use-cases are outliers, and my approach will be deemed naive by the community… I’m happy to learn better ways of doing things in Swift, and welcome any thoughts, criticism, or illumination related to these ideas.
I’m including the write-up b…
Hello all,
TJ Usiyan, Harlan Haskins, and I have been working on a proposal to rework qualified imports and introduce an explicit module system to Swift that we’d like to publish for your viewing pleasure.
The initial impetus was set out in a radar (rdar://17630570) I sent fairly early on that didn’t receive a response, so I started a swift-evolution <http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1378> ; thread discussing the basics of this proposal. It has been refined and expa…
My 2c on this:
Syntactically, we should have a definition of a namespace, like this:
namespace Foo {}
and given that it should probably have braces, it should allow things to be defined inside of it explicitly. However, I agree we don't want to have entire files nested under namespaces. Something file-based like Java's package system is one very reasonable approach on this: a definition in the file specifies the default namespace for everything within it.
Another (complementary) approach w…
If I've missed any proposals, let me know and I'll add them here. Just don't send me the unrevised "scope based submodules" proposal, I left that out deliberately.
7 Likes
Ponyboy47
May 10, 2018, 6:16pm
4
I think this one also applies:
My 2c on this:
Syntactically, we should have a definition of a namespace, like this:
namespace Foo {}
and given that it should probably have braces, it should allow things to be defined inside of it explicitly. However, I agree we don't want to have entire files nested under namespaces. Something file-based like Java's package system is one very reasonable approach on this: a definition in the file specifies the default namespace for everything within it.
Another (complementary) approach w…