Add OperationId combinator.

[devinlyons]

No description provided.

[phadej]

I don't think this belongs to servant. A separate package maybe.

cc @alpmestan

[alpmestan]

I have to admit I'm a little bit "bothered" the swagger-specific nature of this combinator. Description/Summary seem general enough to be useful for all sorts of docs-oriented interpretations of API types, while "operation id" seems to be harder to motivate if the only use case lives in the -swagger pkgs.

Any chance this could be useful elsewhere than -swagger?

[devinlyons]

I don't think it will have any use beyond swagger. Perhaps I can move it to the servant-swagger library. However, that would add a servant-swagger dependency to any servant-client based library that uses the OperationId in the routes. The last option is to create new packages I guess. Thoughts?

[devinlyons]

I see this is a duplicate of #1237. Perhaps I should just close this and let the existing PR deal with the issue.

[alpmestan]

I think this definitely makes sense as its own little lightweight package. I have myself published a couple of such packages, to avoid "bloating" the core libs with deps and code that only a tiny fraction of users might ever care about (servant-ede, servant-generate, ...).

[roberth]

I think this definitely makes sense as its own little lightweight package.

It could be done, but the problem with custom combinators is that all packages that interact with servant apis have to support it.
So it wouldn't be just servant-operation-id, but also servant-server-operation-id (with a no-op instance), servant-client-core-operation-id, etc, etc.
(This is an instance of the expression problem.)

By adding OperationId (or something more generic, which I guess is preferable), you make this overhead go away. Each existent package can implement their instances for it cheaply, without incurring an extra dependency.

IMO Hackage, Cabal and GHC should holistically solve the expression problem (of orphan instances), but I can't tell whether that would be within the ambitions of the ecosystem.

[tchoutri]

@roberth Do you reckon this combinator should rather live in servant-openapi3?

[roberth]

I don't, because then we'd have to convince all the other libraries to add the package for the sole reason of importing OperationId and ignoring it. Seems like a tough sell, especially if the package defines more than just the combinator.
A separate servant-operation-id would be better than adding it to servant-openapi3, but I think it's over-engineered compared to just adding it to servant.