Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subscripts as alternative to operators #142

Open
Anviking opened this issue Mar 1, 2017 · 0 comments
Open

Subscripts as alternative to operators #142

Anviking opened this issue Mar 1, 2017 · 0 comments

Comments

@Anviking
Copy link
Owner

Anviking commented Mar 1, 2017

We would perhaps soon have the opportunity to introduce subscripts as an alternative to operators. Here are some hasty thoughts:

Pros:

  • Can record A LOT of metadata using implicit parameters
  • Perhaps looks nicer

Cons:

  • Requires some redesign (although I've wanted to move in this direction anyways)
  • Requires JSON type, does not work with Any. In a lot of ways this makes sense though.

I'm pretty sure this would work:

let v: String? = root["a"]["b"]?["c"]
a and b are allow null, c does not allow null

If you want "c" to allow null, you'd have to mark it explicitly with another syntax. Perhaps with

["key".allow(.null, .missingKey, ...)]

There is a choice here whether to have all subscripts returning JSON structs, or whether to construct KeyPaths for as long as possible. I don't think there is an obvious advantage to any; try-catch-path-appending shenanigans are unavoidable, and being able to construct KeyPaths is nice.

With conditional protocol conformance, the need to generate overloads would go a way, so it would probably be easy to keep supporting the operator syntax.

@Anviking Anviking changed the title Subscripts Subscripts as alternative to operators Mar 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant