WIP: Free fns for Output constructors and add prelude

[killercup]

Based on #74, cf. https://github.com/killercup/assert_cli/pull/74#pullrequestreview-72693665

• [x] No, I did not try to fix all the tests this is just a WIP to discuss if we want this

[killercup]

@epage what do you think of this? (You just need to look at the second commit)

[epage]

I'm hoping this isn't pride but I think I prefer the original solution.

• Maybe I'm letting my python background through but I dislike wildcard use. I think preludes make sense for traits but thats it.
• Serves better for progressive disclosure.
  • Docs and auto-completion only show you whats generally relevant. Once you decide to mess with Output, it starts to show you more options.

Thoughts? If you agree, I'll go ahead and fix up your suggestions on #74.

[killercup]

@epage I usually agree with wildcard imports being bad, but preludes are a special use case as they only re-export the things that you'd usually import anyway. But that's not the main point of the PR, you can expand the glob import—that's actually the one fancy refactoring feature the RLS has currently! Or do something like use assert_cli::ouput::predicates as output;. :)

What do you think about using free functions instead of constructors on Output? My main concern here is making test code be concise and expressive (both when reading and writing it), and I think .stderr(Output::is("foo")) is just that one tad too verbose. stderr is an output, so writing output a second time doesn't help much.

[epage]

High level: I understand the desire to make the API less verbose. I think this is a case of us having slightly different priorities in API design. So I'd call it a tie with you breaking the tie in the direction you see fit.

If you go forward with this PR, we should have at least once one example not using a prelude to help people if there is a symbol conflict

Details (continued):

• If we encourage use assert_cli::ouput::predicates as output;, what happens if we add a trait in the future?
• Regarding free factory functions: I put a slightly higher priority on consistent API design over being less verbose. People expect factories to be on the type they create.
• The factory being on the type provides symmetry with Environment

[epage]

Before working on #80, we should probably decide between

• Are predicates factories or free functions
• Whether to have a prelude (Of course #74 being the other approach).

to avoid major conflicts between the output work for #80 and this.

[killercup]

Sorry, I'd love to make progress here. I really feel like I should spend some time thinking about this and maybe experimenting with more real-world code; but I don't have much time right now :( So I'd be open to gather arguments from more people and figuring out a general consensus.

[epage]

Seems reasonable.