@josevalim: Done.
For all interested more info in #7147: Could not call defguard check inside defguard. issue.
Update: Bug confirmed and fixed in 6aadfba586b22b22550e9d839a3c89d27224579b commit.
@josevalim: Done.
For all interested more info in #7147: Could not call defguard check inside defguard. issue.
Update: Bug confirmed and fixed in 6aadfba586b22b22550e9d839a3c89d27224579b commit.
@josevalim: Sorry for ping you again, but I donât understand why I got same warning (I corrected my guards).
defmodule Example do
defguardp is_rgb_integer(tuple, index) when elem(tuple, index) in 0..255
defguardp is_rgb_base(rgb)
when is_rgb_integer(rgb, 0) and is_rgb_integer(rgb, 1) and is_rgb_integer(rgb, 2)
defguard is_css_alpha(alpha) when alpha >= 0 and alpha <= 1
defguardp is_rba_css_alhpa(tuple) when tuple |> elem(3) |> is_css_alpha()
defguard is_rgba(rgba)
when is_tuple(rgba) and tuple_size(rgba) == 4 and is_rgb_base(rgba) and
is_rba_css_alhpa(rgba)
defguard is_rgb(rgba)
when is_tuple(rgba) and
(tuple_size(rgba) == 3 or (tuple_size(rgba) == 4 and is_rba_css_alhpa(rgba))) and
is_rgb_base(rgba)
end
My changes were to make some guards private and donât called twice, but Iâm getting this: warning: this expression will fail with ArgumentError
I wrote smaller example that generates same error:
defmodule Example do
defguard test_me(rgba)
when is_tuple(rgba) and
( # comment this
tuple_size(rgba) == 4
and elem(rgba, 3) == :ok
) # comment this
end
# and in another file:
require Example
Example.test_me({1, 2})
Now try to comment lines with (
and )
characters (as in comments) and recompile project. Warning will not appear now.
Is it a bug too?
The warning itself is not a bug because the compiler is being smart and saying: âthis will always failâ. That happens because you are passing a literal and the compiler can figure it all out. If you move the tuple to a variable instead of passing it directly to the guard, then the compiler should stay quiet.
I would say the warning in the last example is wrong though, it wonât âfail with ArgumentErrorâ, but it will âalways return falseâ. Although the wrong messaging is a bug in Erlang, not in Elixir.
ok, makes sense - really thanks for explanation
@josevalim Is there planned support for a max column width option in the formatter? Most of my codebases wrap at 80 chars, but the formatter will unwrap anything between 80 and 100 chars. I can restructure most things to keep the limit, but seem to be out of luck for long aliases and functions with guard clauses.
It is already there, please check the docs.
Sorry, guess I totally missed it.
Which page? Thereâs nothing about it on https://hexdocs.pm/mix/master/Mix.Tasks.Format.html, is there?
Please take a look at: Code.format_string!/2
Parsed options are applied directly to it.
See:
format.ex:129
format.ex: 281
Docs says:
Formatting is done with the Code.format_string!/2 function. A .formatter.exs file can also be defined for customizing input files and the formatter itself.
So anyone reading docs should at least check it, but I donât found that parsed arguments are passed directly to it!
To be honest there is a section for arguments where no length is described and next section called .formatter.exs
describes extra arguments. Keeping in mind that there is no info that arguments are passed to linked function it could be wrong interpreted like:
There are no more options other than described, however
.formatter.exs
supports few more. Unfortunately there are also no such option supported there.`
Reading this first time I through similarly. I was need to read source of this task to be sure.
btw. @josevalim
I found that this link for docs in v1.7.0-dev
points towards v1.5.3
version which is big mistake, because this version does not have implemented linked function!
The link that doesnât work is a lesser problem than options for mix format
not being listed on the one page you would expect them, but yes, the link working exacerbates that considerably.
Author of this probably wanted to say that these options are task-specific only. There is no need to describe same options in multiple places. The real problem is text (and itâs location) that links to rest of options - it could be missed.
I think that sentence with this link should be a little changed and moved to Options
section, so it will be easier to find it.
If the docs are not clear, please send a PR.
The issue with us not linking to the proper Elixir version has been fixed on ex_doc master.
Thanks!
There is. mix format
is user-facing and itâs obviously where people will be looking for âHow do I configure it?â. Any options you can use should be availabe in the CLI with mix help format
as thatâs likely what people will check first. Iâd never bother actually checking the online docs unless someone told me something I couldnât see with mix help format
was available.
If we donât want to duplicate text, we should at least make function documentation embeddable on other docs pages so that this kind of indirection in docs doesnât hide useful information, in my opinion.
This is a good idea, but I think there is currently no implementation for it - at least I donât know it.
I have created #7150 PR to make options part more clear, so you will see that you need to check docs of this function in order to get all formatting options and with it you will not have a need to check online docs.
Really though my library is purposefully incomplete and a hack (I redefine def
and so forth). It is something that should be done properly in the elixir core, but theyâve stated this feature is not planned due to various edge cases that are hard to work around.
@OvermindDL1: Nice, but.
Do you have a time to change it in your library?
How long are release candidates usually take to release?
Depends on few things. This release introduce lots of really usable changes that I would like to test, so I believe that it requires more time for testing them. Last time I tested new guards and rest I donât even tried yet - I donât have a time for it, so some other people probably too. Next things I will test tomorrow.
I think that it have a chance to be ready between 2nd and 3rd week of January. At least I plan to finish testing in this or next week and remember that itâs only my plans. I believe that some people that want to help could not even start work with it - job, family and rest time. For some people real work could start at 1st or 2nd January.
Thanks Eiji
It depends on how much feedback we get and how much of this feedback is positive. We will probably do another RC around 4th or 5th January, and the final version at most a week after that (assuming that there are no reports).