Language enhancement: Nest enum declaration into protocol declaration

Hi fellow Swifters,

I have just started using the language and was trying to declare an enum inside a protocol.

protocol WorkingEngine {
   enum States {
    Idle
        Pending
        Working
        Finished
        Canceled
  }

  var state: States { get }
}

The compiler refused this and I had to take the enum outside of the protocol:

enum WorkingEngineStates {
    Idle
        Pending
        Working
        Finished
        Canceled
  }

protocol WorkingEngine {
  var state: WorkingEngineStates { get }
}

This does not seem coherent with the rest of the language, as enums can be nested in classes, structs and even enums, but not to protocols.
I haven’t found any proposal for this change. Is this the correct place to request it or get some opinion on the idea?

Thanks a lot,

Jakub

Actually this is very consistent. You can not nest data structures like
enums, structs, or classes in a protocol. This is because a protocol is
meant to be a list of variables and functions that data structures may
conform to. A protocol is not a data structure.

···

On Mon, Nov 21, 2016 at 7:33 AM Jakub Bednář via swift-evolution < swift-evolution@swift.org> wrote:

Hi fellow Swifters,

I have just started using the language and was trying to declare an enum
inside a protocol.

protocol WorkingEngine {
   enum States {
        Idle
        Pending
        Working
        Finished
        Canceled
  }

  var state: States { get }
}

The compiler refused this and I had to take the enum outside of the
protocol:

enum WorkingEngineStates {
        Idle
        Pending
        Working
        Finished
        Canceled
  }

protocol WorkingEngine {
  var state: WorkingEngineStates { get }
}

This does not seem coherent with the rest of the language, as enums can be
nested in classes, structs and even enums, but not to protocols.
I haven’t found any proposal for this change. Is this the correct place to
request it or get some opinion on the idea?

Thanks a lot,

Jakub

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

Proposal is being worked on. Ease restrictions on protocol nesting by karwa · Pull Request #552 · apple/swift-evolution · GitHub
  
- Karl

···

  
On Nov 21, 2016 at 1:33 pm, <Jakub Bednář via swift-evolution (mailto:swift-evolution@swift.org)> wrote:
  
Hi fellow Swifters,

I have just started using the language and was trying to declare an enum inside a protocol.

protocol WorkingEngine {
enum States {
Idle
Pending
Working
Finished
Canceled
}

var state: States { get }
}

The compiler refused this and I had to take the enum outside of the protocol:

enum WorkingEngineStates {
Idle
Pending
Working
Finished
Canceled
}

protocol WorkingEngine {
var state: WorkingEngineStates { get }
}

This does not seem coherent with the rest of the language, as enums can be nested in classes, structs and even enums, but not to protocols.
I haven’t found any proposal for this change. Is this the correct place to request it or get some opinion on the idea?

Thanks a lot,

Jakub

_______________________________________________
swift-evolution mailing list (mailto:listswift-evolution@swift.orghttps)
swift-evolution@swift.org (mailto:listswift-evolution@swift.orghttps)
https (mailto:listswift-evolution@swift.orghttps)://lists.swift.org/mailman/listinfo/swift-evolution

What I am really missing is tying the enum to that protocol. I would like to write something like WorkingEngine.States.Idle.

In C# you can use namespace to do so, as their interface declarations can’t nest types either.
In C++ you can use either namespace or nest enum inside a virtual class.
In Objective-C and Swift probably the best way is to declare the enum in the same file as the protocol and use the name of the protocol as prefix to the name of the enum.

I thought Swift might improve on this a bit. It is definitely not a functional thing, rather a code-navigation/readability thing.

J.

···

On Nov 21, 2016, at 2:29 PM, Derrick Ho <wh1pch81n@gmail.com<mailto:wh1pch81n@gmail.com>> wrote:

Actually this is very consistent. You can not nest data structures like enums, structs, or classes in a protocol. This is because a protocol is meant to be a list of variables and functions that data structures may conform to. A protocol is not a data structure.
On Mon, Nov 21, 2016 at 7:33 AM Jakub Bednář via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
Hi fellow Swifters,

I have just started using the language and was trying to declare an enum inside a protocol.

protocol WorkingEngine {
   enum States {
        Idle
        Pending
        Working
        Finished
        Canceled
  }

  var state: States { get }
}

The compiler refused this and I had to take the enum outside of the protocol:

enum WorkingEngineStates {
        Idle
        Pending
        Working
        Finished
        Canceled
  }

protocol WorkingEngine {
  var state: WorkingEngineStates { get }
}

This does not seem coherent with the rest of the language, as enums can be nested in classes, structs and even enums, but not to protocols.
I haven’t found any proposal for this change. Is this the correct place to request it or get some opinion on the idea?

Thanks a lot,

Jakub

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

While that's generally correct, a nested type isn't really part of the type that it comes within; it's still a discreet type stored elsewhere, the nesting is just to make it a bit nicer to work with, rather than defining types with overly long names. It's more of a naming/grouping system.

I'm generally in favour of allow nested types for protocols personally, as really the only caveat is that it may make collisions more likely; for example if several protocols have a nested type of ReturnType, or Node or whatever then you'll have to also name the parent type when referencing them, though in most cases type inference may prevent this from being much a problem.

So yeah, I think there's definitely an argument to be made for specifying nested types in order to define protocol-specific enums especially. The only question really is whether support for sub-modules will overlap, and which is the better solution; nested types would have an advantage of being simple and intuitive though.

···

On 21 Nov 2016, at 13:29, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:

Actually this is very consistent. You can not nest data structures like enums, structs, or classes in a protocol. This is because a protocol is meant to be a list of variables and functions that data structures may conform to. A protocol is not a data structure.

Jakub, try this...

struct WorkingEngine {
enum States {
case idle
}
}

Then you can call it

WorkingEngine.States.idle

···

On Mon, Nov 21, 2016 at 9:56 AM Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote:

Proposal is being worked on.
Ease restrictions on protocol nesting by karwa · Pull Request #552 · apple/swift-evolution · GitHub

- Karl

On Nov 21, 2016 at 1:33 pm, <Jakub Bednář via swift-evolution > <swift-evolution@swift.org>> wrote:

Hi fellow Swifters,

I have just started using the language and was trying to declare an enum inside a protocol.

protocol WorkingEngine {
   enum States {
    Idle
        Pending
        Working
        Finished
        Canceled
  }

  var state: States { get }
}

The compiler refused this and I had to take the enum outside of the protocol:

enum WorkingEngineStates {
    Idle
        Pending
        Working
        Finished
        Canceled
  }

protocol WorkingEngine {
  var state: WorkingEngineStates { get }
}

This does not seem coherent with the rest of the language, as enums can be nested in classes, structs and even enums, but not to protocols.
I haven’t found any proposal for this change. Is this the correct place to request it or get some opinion on the idea?

Thanks a lot,

Jakub

_______________________________________________
swift-evolution mailing list <listswift-evolution@swift.orghttps>
swift-evolution@swift.org <listswift-evolution@swift.orghttps>
https <listswift-evolution@swift.orghttps>://lists.swift.org/mailman/listinfo/swift-evolution

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