AutomaticSettingsEnum and RawRepresentable

[IlyaPuchkaTW]

I think considering that enums should be Codable we don't have to make them RawRepresentable in AutomaticSettingsEnum protocol. We can make them CustomStringConvertible for representing their value in UI, although that's not covering all possible cases either, so it would be more extensible if it would be a custom AutomaticSettingsPresentable protocol that returns any view.

The use case I have is to use AutomaticSettings to configure SwiftUI views from their set of props and often these props can't be represented just by a string. For example it can be a color and then we can have a color picker to choose from it (or any custom view client wants to use for that, it shouldn't be part of the library), or it can be an image then client might want to show image picker. Another use case is to have nested settings represented as enum with associated values, they can't have raw value, but can be Codable and can be CustomStringConvertible or implement proposed AutomaticSettingsPresentable.

Here is what I put together so far, here I had to flatten enum that could have used nested enum for "avatar" prop:

https://user-images.githubusercontent.com/68597557/109497254-aad31300-7a89-11eb-81b0-094088866b8f.mp4

[krzysztofzablocki]

@IlyaPuchkaTW how'd you imagine AutomaticSettingsPresentable protocol? because what I do right now is I leverage the function DSL I build here to extend the library in my projects for custom types, e.g.

extension AutomaticSettingsViewDSL {
    @_disfavoredOverload
    func setting(_ name: String, keyPath: WritableKeyPath<Settings, Version?>, requiresRestart: Bool = false, sideEffect: (() -> Void)? = nil, uniqueIdentifier: String) -> some View 

and then the typesystem just finds right override and calls it creating custom UI elements for app non standard types

[IlyaPuchkaTW]

I didn't look deep into the implementation details but I guess I can try to use this attribute to come up with something that will fit my use case.