Re: [swift-evolution] [Swift4] Mailing list vs. Forum

It’s not that nobody cares, it’s that it’s ultimately up to Apple to decided how this is going to go, and nobody there seems to care. Until a decision is made there, nothing will happen. Even under the best case scenario I wouldn’t expect anything to happen soon, as Apple doesn’t move quickly

Re: [swift-evolution] [Proposal] Enums with stored properties

I’ve started doing this to try and mimic “Smart Constructors” in Haskell and I think it works quite well. struct Format { enum FormatBacking { case SMALL(Int, Int) case MEDIUM(Int, Int) case LARGE(Int, Int) } private let unFormat : FormatBacking static var Small : Format {

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

On Sat, Oct 8, 2016 at 4:00 AM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > It’s one of those issues where everybody agrees we could do better but > nobody cares enough to do anything about it. > No, I think if you read this thread (and the others) I think you'll find that not

Re: [swift-evolution] private & fileprivate

Sent from my iPad > On Oct 8, 2016, at 5:58 PM, Xiaodi Wu wrote: > > Very much agree with essentially all of that. > > Personally, I'd also want to explore whether any submodule scope could just > subsume fileprivate (i.e., files not otherwise in a submodule behave as

Re: [swift-evolution] private & fileprivate

Very much agree with essentially all of that. Personally, I'd also want to explore whether any submodule scope could just subsume fileprivate (i.e., files not otherwise in a submodule behave as though they are their own submodule for access control purposes) rather than occupy another slot

Re: [swift-evolution] [Proposal] Enums with stored properties

I agree, you can achieve similar result using structs (as shown in my example 2). But it feels more natural to define it using an enumeration type. Enumeration defines a type with well defined set of possible values. Sometimes where are additional informations liked with enumeration cases (like in

[swift-evolution] [Proposal] Enums with stored properties

This is precisely what a struct is for, why would you want to be able to do this with enums instead? > Hi all, > I would like to know you opinion on one feature I feel would be a real 'nice > to have' extension to currently available enumeration type. Which is an > enumeration type with stored

Re: [swift-evolution] private & fileprivate

On Sat, Oct 8, 2016 at 3:24 PM, Karl wrote: > > On 8 Oct 2016, at 21:01, Xiaodi Wu wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution evolut...@swift.org> wrote: > >> >> On 8 Oct 2016, at 16:47, Braeden Profile

Re: [swift-evolution] private & fileprivate

On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson wrote: > > On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On 8 Oct

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 21:01, Xiaodi Wu wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > > wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile >

Re: [swift-evolution] private & fileprivate

> On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > > wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile

Re: [swift-evolution] private & fileprivate

On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > > On 8 Oct 2016, at 16:47, Braeden Profile wrote: > > > On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > I was thinking that the

[swift-evolution] [Proposal] Enums with stored properties

Hi all, I would like to know you opinion on one feature I feel would be a real 'nice to have' extension to currently available enumeration type. Which is an enumeration type with stored properties. It is sometimes useful to store some extra informations along with enumeration cases. Idea here is

Re: [swift-evolution] private & fileprivate

> On 08 Oct 2016, at 19:17, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Oct 8, 2016, at 12:02 PM, Karl via swift-evolution > wrote: > >> >>> On 8 Oct 2016, at 16:47, Braeden Profile

Re: [swift-evolution] private & fileprivate

> > On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution > wrote: > > I was thinking that the domains themselves could be associated with a domain, > so you could create alternate domains which are also publicly-visible, but > distinct from the default, “public”

Re: [swift-evolution] private & fileprivate

As far as I can see, almost all people, who talk here, agree that private / fileprivate distinction brought more harm than good. Despite corresponding proposal being accepted. I think, it means that current mailing-list system is failing. Let's accept it, gmane looks and feels ugly by comparison

Re: [swift-evolution] private & fileprivate

I was thinking that the domains themselves could be associated with a domain, so you could create alternate domains which are also publicly-visible, but distinct from the default, “public” domain. For example, if you have a bunch of methods which should be visible to subclasses, but you don’t

Re: [swift-evolution] private & fileprivate

I agree something like you suggest will give a lot of flexibility without - I think - the IMHO quirkiness of friends in C++. It seems like the access domains must? be limited to inside a module to avoid potential surprises from outside the module? -Shawn On Sat, Oct 8, 2016 at 3:38 AM Karl via

Re: [swift-evolution] associated objects

> On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution > wrote: > > I have implemented Associated Objects (and values) in pure swift here: > https://github.com/j-h-a/AssociatedObjects > > > The README is very short

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

It’s one of those issues where everybody agrees we could do better but nobody cares enough to do anything about it. In any case I think Discourse seemed to be the only real option because of mailing-list support. So I suppose they next step would be to submit a formal proposal to swift-evo on

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution > wrote: > > >> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution >> wrote: >> personally I thought `private` was fine the way it was when it meant >> `fileprivate` and I

Re: [swift-evolution] private & fileprivate

> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution > wrote: > personally I thought `private` was fine the way it was when it meant > `fileprivate` and I had no real need for `private` as it exists in Swift 3. I have to agree with this; I wasn't especially

Re: [swift-evolution] private & fileprivate

I would rather consider using a new keyword that could make it clearer without looking up for description. NewCurrent moduleprivate over internal On Sat, Oct 8, 2016 at 2:44 PM, Rien via swift-evolution < swift-evolution@swift.org> wrote: > +1 for me. > > I see a

Re: [swift-evolution] private & fileprivate

+1 for me. I see a little benefit for teams that have multiple people working on a single file (not necessarily at the same time) where a case can be made for a distinction between fileprivate and private. Other than that there is imo no benefit. So to me the question is “is the benefit to

Re: [swift-evolution] private & fileprivate

Comments inline: > On 8 Oct 2016, at 00:56, Jordan Rose via swift-evolution > wrote: > > >>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution >>> wrote: >>> >>> >>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via