-
Notifications
You must be signed in to change notification settings - Fork 247
[Import] Codata.*
#2616
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
[Import] Codata.*
#2616
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good (but again, need to wait for CI)
See my comment on #2617 about UPDATED: I guess after looking again at that merged PR, that I now accept, albeit reluctantly, the explicit mention of the 'musical' notation. I think that it might be useful separately, perhaps under #2339 , to discuss whether it is a good idea or not to explicit expose the API of a given import in this way, in terms of knock-on viscosity (but I take the spirit of @JacquesCarette 's intentions, and @jmougeot 's implementations in this series of PRs, to be: yes, it's worth the cost, because this is a way of seeing upfront what has to be paid, rather than having to search for it, or be taken by surprise by it, later) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given all this activity in 'regularising' the role of import
s with using
directives, standardising the order of names mentioned (type before constructors, constructors before functions, functions before relations, or simply 'module dependency order'?) seems a good idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Time to merge!
No description provided.