What would a strict mode in Julia look like? Would it apply at the parsing stage (e.g., as a VS Code extension or a REPL flag) or during compilation (e.g., by toggling type inference warnings with a flag)?
Iād love to discuss thisāwhy it hasnāt been implemented yet, the challenges involved, and whether or not it would be desirable, depending on different perspectives.
I know that AllocCheck, Aqua, and their counterparts are available and greatly help in development. However, for newcomersāsuch as Fortran, C++, or Rust usersāwho are already familiar with strict typing and just need a bit of guidance to avoid common pitfalls, having a stricter mode could be useful. It could help prevent mistakes and mitigate the frustration that might arise when porting a large codebase to Julia.
Also, we would need to choose between warning-strict and error-strict, this is quite different.
Iāve readen a little and this seems to be error-strict and on parsing (macro based) It does not seem like they discuss why this and not warning or why not compiler based. Iām also not sure someone should change the code to check if he is doing bad things, a repl/parser mode seems to be a lot friendlyer.
Thereās not much discussion about implementation because itās still very hypothetical. That said, restricting code to a subset of a language would most naturally be done at the parsing stage. For example, you can immediately tell when structs have implicit Any fields when the expression is parsed; doing it later is possible but itād take more work, and thereās no reason the compiler has to be the one to do it.
It might help in some small ways but I doubt it can make porting code significantly easier. A one-to-one bijection of syntax and semantics is easy, and that sort of coordination isnāt typical between languages. Restricting to a subset might actually make things worse by sabotaging reimplementation patterns.
If parsing is sufficient to enforce the subset restriction, then using it is reasonable.
However, this doesnāt mean that one should use macros just to prevent mistakes there are already plenty of packages available for such checks.
I didnāt claim that restricting to a subset would make porting easier; in fact, it might make it harder.
However, it would almost certainly reduce disappointment in terms of runtime performance afterwards.
Also, if itās only clear warning based and easy to toggle it wonāt change there code just to check.
yes or just a repl flag actually running julia with --typestable (will error or warn if something is not type stable), --static (will error if something allocates beside compilation) and --strict (type stable + all other things discussed in the strict subset) depending on what the user wants
I think global command-line switches would lead to poor adoption because they would likely restrict you from calling the majority of existing packages, including Base and the standard library. Certainly for the strict mode discussed in the github issue, the idea is that it will be configured per package, not globally for the Julia session. Also itās focused on syntax, not on behaviors and performance aspects of the resulting program, such as type stability and allocationācheck out DispatchDoctor.jl and AllocCheck.jl for that. (Though, of course, the two are often related because many syntax footguns make the compilerās life harder.)
Oh ok, I guess DispatchDoctor set_preferences!("MyPackage", "dispatch_doctor_mode" => "error") or set_preferences!("MyPackage", "dispatch_doctor_mode" => "warn") is the way to go for now, having this in repl would help a lot I think, I agree with you about Base and tons of other packages that may not work with it enable and I donāt see a solution for that beside considering non-local function to be type safe by default even though itās false.