Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On 19 Jul 2016, at 00:09, Robert Widmann via swift-evolution > wrote: > > 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

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

I’m not a fan of renaming. Along with ‘dialects’ of the Swift language itself, allowing people to rename APIs (because they don’t like Apple’s long names) makes it harder for everybody else to understand. I know people who do this at the moment with typedefs/typealiases. Drives me nuts.

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Totally agree with Joe here. I’d like to see a simplified version of the import design through ASAP. Mot people will quickly agree with it. The rest of the proposal is much more up for discussion IMHO. > On 19 Jul 2016, at 03:19, Joe Groff via swift-evolution >

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Import Foo.* as bar.// has public methodX() and type TypeA Import Foo2.* as baz. // also has public methodX() and type TypeA would be interesting because it entirely avoids collisions when using both together. It also provides some documentation at the point of use, as well as allow the IDE

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

There is no effective difference between renaming to a dummy name and hiding. In fact, renaming (Int, to: _) could do that. Félix > Le 18 juil. 2016 à 22:04:44, T.J. Usiyan via swift-evolution > a écrit : > > Haskell has much more than import everything and import

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Haskell has much more than import everything and import itemized. https://wiki.haskell.org/Import Hiding is important for avoiding collisions of name and/or function. On Mon, Jul 18, 2016 at 9:19 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Our import story definitely

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

My gut feeling is also that this is more complex than it needs to be. If we want to keep all of these features around, I'd be in favor of looking for a syntax that "flows better" than three separate clauses. Also, under the current model (or a somewhat recent model, because I ran into that

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Our import story definitely needs work, and this is a step in the right direction. Thanks for working on this! Some comments: - The import changes can be separated from the submodule issues. Enhancing imports is IMO more important, and is source-breaking today, whereas 'module ' declarations

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

On Mon, Jul 18, 2016 at 4:09 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > 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

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 6:01 PM, Brent Royal-Gordon > wrote: > >> On Jul 18, 2016, at 5:33 PM, Robert Widmann wrote: >> >>> 2. Filenames are freeform; any file can declare itself to belong to any >>> submodule. Obviously, best practice would be to

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 5:33 PM, Robert Widmann wrote: > >> 2. Filenames are freeform; any file can declare itself to belong to any >> submodule. Obviously, best practice would be to give your files sensible >> names that have some kind of link to the submodule name, but this

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

What about using duplicate declarations to indicate that two files are part of the same module? On Mon, Jul 18, 2016 at 8:33 PM, Robert Widmann wrote: > > > On Jul 18, 2016, at 5:26 PM, Brent Royal-Gordon > wrote: > > > >> On Jul 18, 2016, at 4:50

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 5:26 PM, Brent Royal-Gordon > wrote: > >> On Jul 18, 2016, at 4:50 PM, T.J. Usiyan wrote: >> >> * You may need to split a single submodule across multiple files, but this >> rule doesn't allow that. >> >> You can,

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 4:50 PM, T.J. Usiyan wrote: > > * You may need to split a single submodule across multiple files, but this > rule doesn't allow that. > > You can, internally, have several modules and then create one that imports > those smaller ones publicly with

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 4:34 PM, Brent Royal-Gordon > wrote: > >> On Jul 18, 2016, at 2:09 PM, Robert Widmann via swift-evolution >> wrote: >> >> Hello all, >> >> TJ Usiyan, Harlan Haskins, and I have been working on a proposal to rework >>

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> > > Modules names are tied to a directory structure that describes their > location relative to the current module and it will now be an error to > violate this rule. For example: > > > > module String // lives in ./String.swift > > > > module String.Core // lives in ./String/Core.swift > > > >

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 4:30 PM, John McCall wrote: > >> >> On Jul 18, 2016, at 3:53 PM, Robert Widmann > > wrote: >> >> >>> On Jul 18, 2016, at 3:21 PM, John McCall >> >

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 2:09 PM, Robert Widmann via swift-evolution > wrote: > > 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

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 3:53 PM, Robert Widmann wrote: > > >> On Jul 18, 2016, at 3:21 PM, John McCall > > wrote: >> >>> >>> On Jul 18, 2016, at 2:09 PM, Robert Widmann via swift-evolution >>>

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 3:21 PM, John McCall wrote: > >> >> On Jul 18, 2016, at 2:09 PM, Robert Widmann via swift-evolution >> > wrote: >> >> Hello all, >> >> TJ Usiyan, Harlan Haskins, and I have been working on

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> is changed so that, outside the module, it has a member `frobnicate()` and > no longer has a member `bobnicate()`? *Unchanged. Other than that, you’ve got it! I wanted to make *very* sure that whatever APIs come in are the same ones that go out regardless of local changes. > On Jul 18,

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 2:09 PM, Robert Widmann via swift-evolution > wrote: > > 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

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

On Mon, Jul 18, 2016 at 5:09 PM, Robert Widmann wrote: > > On Jul 18, 2016, at 3:00 PM, Xiaodi Wu wrote: > > On Mon, Jul 18, 2016 at 4:49 PM, Robert Widmann > wrote: > >> >> On Jul 18, 2016, at 2:32 PM, Xiaodi Wu

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 2:57 PM, Daniel Resnick wrote: > > Modules names are tied to a directory structure that describes their location > relative to the current module and it will now be an error to violate this > rule > What is the rationale for this rule? I realize

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 3:00 PM, Xiaodi Wu wrote: > > On Mon, Jul 18, 2016 at 4:49 PM, Robert Widmann > wrote: > >> On Jul 18, 2016, at 2:32 PM, Xiaodi Wu > > wrote: >> >>

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Interesting... mix of c# and swift and others I am not sure it has many chances to see the light: unless they internally manage to cheat and reuse the natural scoping provided by empty enums, the implications on the binary structure of the dylibs are kolossal... and as if this was not enough,

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> > Modules names are tied to a directory structure that describes their > location relative to the current module and it will now be an error to > violate this rule What is the rationale for this rule? I realize this is a common convention but what is gained from strictly enforcing it? On Mon,

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> On Jul 18, 2016, at 2:32 PM, Xiaodi Wu wrote: > > This is an interesting document. I think it deserves careful study. For now, > some questions: > > What is the rationale behind permitting the using of specific methods? This > seems to be usually fine-grained in

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

This is an interesting document. I think it deserves careful study. For now, some questions: What is the rationale behind permitting the using of specific methods? This seems to be usually fine-grained in comparison to other languages. What use cases do you have in mind for this? I can see the

[swift-evolution] [Proposal] Qualified Imports and Modules

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