Discussion: turn on -strict-sequence by default


#1

OCaml is a curried language, for beginners (even for advanced users), it is easy to have a curried function only partially applied (in refactoring for example).

To avoid such confusions, we plan to enable this by default, if there is a strong demand, we can
add a flag -bs-no-strict-sequence so that it can be explicitly turned off.

Community feedback is very welcome, thanks!


#2

Hi Bob, what will be turned on by default?


#3

-strict-sequence (link)

This sounds like an improvement to me. I personally don’t think there’s the need for a flag to disable it. Getting BuckleScript out of yet another legacy mode sounds amazing.


#4

Oh–so e.g., this will be an error instead of just a warning 10:

let x = {
  1;
  2;
};

Sounds good to me! :slight_smile:

Actually I’m confused why there’s even a -strict-sequence and a separate warning 10 which do the same thing :thinking: I guess a little vestigial OCaml legacy.


#5

Definitely feels like an improvement, what would be the reasons to disable this?


#6

Agreed, I see no reason to keep this even as an option.


#7

the only concern is that it may make some code not compile due to more strict check


#8

Not exactly true.


#9

I read this message carefully, what’s your opinion on this?
We used to have safe-string enabled, which falls the same category


#10

I tend to believe that it is not a blocker. But I am definitely not a compiler expert.


#11

the examples from this thread that have different behaviors whether the flag is enabled or not look a bit sketchy to me but I’m by no mean an expert on the topic. That would probably break a few packages, but a significant part of these cases would probably be bugs anyway so that’d be good in the long term. Since we’re still a very young community and our packages move a lot, I guess it would be doable. If we want to be more cautious we could try to compile the packages from the Redex with this flag enabled.


#12

Thanks for the feedback, it is appreciated!
FYI: we will delay this change after 7.0.2. To make user impact minimal, we will turn it on in warn-error style instead of passing this flag in the future.
It is recommended to have -warn-error +10 now to make your code future-proof