Is let%private discouraged?

ReScript syntax seems to be not very clean.

let%private value = "test"; // ReasonML

gets converted to

%%private(let value = "test") // ReScript

I guess we should rather use interface files, because it is not even documented anymore.

I would even agree with this on the file level, but it is convenient for submodules which you only use internally in one file anyway.

But technically, they’re still available as Module.Submodule and can be abused, so maybe we need module%private instead :slight_smile:

1 Like

This is solved cleanly in OCaml 4.08+ with opening of module literals, so if ReScript upgrades to that next year, we will get that solution automatically:

open {
  let value = "test"
}
6 Likes

Hi, this is not discouraged, it happens to not be documented and contribution to documentation is welcome.
It is indeed a bit ugly that sugar for extension point is not supported.

So, will it get some nicer syntax someday?

Maybe even like F#?

let private value = "test"
2 Likes

I think it’s a good idea, it still makes sense even if we upgrade the upstream. @Maxim thoughts?

2 Likes

sent a PR for the missing docs

1 Like

Thank you, Bob.

It’s already merged in the docs! :tada:

@fham we could indeed add first class syntax support.
What do you think of private let x = "foo"?

4 Likes

There’s no way to make an entire module private without interfaces, right?

In ReScript right now, there is not. In ReScript after upgrading to OCaml 4.08+ (whenever that may happen), the open {module Foo = {...}} would work.

2 Likes

That would also be ok for me.

The open syntax would be very nice. Might it be an idea to backport the feature so we have this syntax pre upgrading to OCaml 4.08? It also eliminates the needs of having a private keyword.

if your submodule only contains value definitions, it should work

%%private(
let a = 3
let b = 2
)

Regardless of whether upgrading or not.
I find private let or let private always more intuitive than open { .. }, the purpose is not to save some characters, it’s that people understand private without any further explanations which already appears in other languages like F# as mentioned above

1 Like

Now that I think of it, should it not be aligned with private for types?

type t = private string

could also be

private type t = string

It’s a bit different though, I don’t know if the two should be mixed up.