External functions are considered side-effect free when compiling for the other target #4788
Replies: 4 comments
-
This function is side effect free, so I'm not immediately sure it makes sense to say that it is not. You could introduce a side effect by giving it an FFI implementation, that would solve your problem here. It is less clear though, that is an annoyance. |
Beta Was this translation helpful? Give feedback.
-
Yeah I guess you could argue that a function that does not support a target at all cannot possibly have side-effects on that target. I think it's very confusing to get warnings like this from another package and FFI code in my app when running a module from a package that uses the other target, though. Another case where I noticed this is that running the tests in a javascript project that depends on |
Beta Was this translation helpful? Give feedback.
-
I think that's an issue with the library today rather than a problem with this system. It's intended to warn about things not having side effects, which is it doing. Perhaps there's some improvements we could make to the system in future... |
Beta Was this translation helpful? Give feedback.
-
I'm not quite sure I understand, sorry. Right now if I run the tests in my Lustre javascript project, I got tons of "unused value" warnings from Erlang-only dependencies that I got through lustre-dev-tools. Are you suggesting these should all ship with a Javascript FFI stub just to silence that warning? Sorry if I wasn't clear originally, I wasn't quite sure which cases this includes when I made that issue. I think if that's intended it would be better to accept that warning for now instead of adding these FFI stubs. big compiler output dump of
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a package called
wibble
, exposing a function that calls some FFI for some side effect:Both my app and this package target javascript in their gleam.toml.
Another package I depend on (in this case lustre_dev_tools) targets erlang. When running
gleam run -m lustre/dev start
, my app and also that package are both compiled for the Erlang target.While doing so, the compiler incorrectly emits a warning that the result value of do_wibble() is unused:
I think the problem here is that
do_wibble
does not have an implementation for Erlang, and that case is assumed to not introduce side effects.~ 💜
Beta Was this translation helpful? Give feedback.
All reactions