-
Notifications
You must be signed in to change notification settings - Fork 1.1k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Introduce a use
keyword for specific open
s
#11558
Comments
(I'm not too sure how hard this would be to implement but I'd be willing to give it a shot if it's not too crazy) |
In OCaml you can do: let encode = Hexstring.encode
let decode = Hexstring.decode Or, shorter: let encode, decode = Hexstring.(encode, decode) |
A new keyword is major breaking change. Moreover, the keyword does not seem required in your syntax proposal, extending
However, the open (Hextring: sig val encode: Bytes.t -> Bytes.t val decode: Bytes.t -> Bytes.t end) This is clearly a too heavy syntactically. But it might be a better starting point for extending the syntax, maybe something like
This syntax also has the advantage of removing the ambiguity between importing types, values, classes, class types or module types in your proposal: module M = struct
type t
module type t
class t
end
use M.{t} (* which `t` is that *) @yallop proposal can be also extended to remove this ambiguity if we allow
|
reusing open is ambiguous though, as it would work differently depending depending on context: open Hexstring (* opens the content of Hexstring *)
open Hexstring.{OtherModule} (* does this open the content of OtherModule, or does it import OtherModule into scope? *) |
Maybe best is:
Or if you really have to:
Topmost selective imports are a mental burden detrimental to code reading, you need to maintain all of these in your brain to read the code. |
The problem is that today people abuse |
It seems to me that nowadays people are sufficiently aware of its problem not to abuse it. Most topmost opens are used for namespacing, eDSLs or let operators.
When reading code below the fold having a bulk open or a selective one makes no difference, both are a mental burden. That's the reason why I don't think this proposal is a good solution. There are more options than you suggest. You can devise linters to forbid bulk opens or devise a warning for when an |
I'm also in favour of adding something like @Octachron's proposal. I have an (unmaintained) ppx for it: https://github.com/johnyob/ppx-open. But like |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I'd like to propose the introduction of a new keyword
use
to avoid opening everything in the scope. This is inspired by Rust and would improve readability. For example:Bad:
Better:
The text was updated successfully, but these errors were encountered: