Okay, thanks for the explanation. The way I found this case is when asking
ChatGPT to give code examples using @type and explain them, in one of its
examples it did this:
@type name_number :: {String.t(), number()}
Then made a function like this:
# Incorrect @spec to induce Dialyzer error
@spec add(pid(), {integer(), integer()}) :: :ok
def add(pid, name_number) do
send pid, {:add, name_number}
:ok
In this case in its explanation it said that the add() function is defined
as a PID and the type name_number (rather than a tuple argument which
happens to be called name_number), which is not true in this example.
I might not have the example perfect, I've been learning Elixir for about a
month.
Thanks for your explanation of why you tend to use simple variable names
like string for the argument in def downcase(string), I now understand that
this doesn't overlap with the namespaces used for types.
Best regards,
Rob
On Fri, Jan 12, 2024 at 7:54 PM José Valim <jose.va...@dashbit.co> wrote:
> > 1. Do you think anyone would purposefully name a variable a type?
> (false positives.)
>
> Yes, we do it in Elixir all the time. Because if I am implementing
> String.downcase/1, the name `string` is a very good name for the argument:
>
> def downcase(string)
>
> And since we use names in the docs, calling it `my_string` may even be
> confusing.
>
> Furthermore, variables and types live in distinct namespaces. There is no
> way one can clobber or shadow the other, so overall this is not a concern.
> There is a concern of a developer choosing a poor variable name, but that's
> not related to types at all. You can give bad names to your variables, even
> if they don't match a type at all. :)
>
> On Fri, Jan 12, 2024 at 7:05 PM Robert Viragh <rvir...@gmail.com> wrote:
>
>> This proposes you should add a warning if a programmer names the variable
>> with the name of a type - what do you think?
>>
>> Motivation
>> Ahead of the recent gradual typing introduction, I was having fun
>> exploring types and was trying to come up with cases that are definitely a
>> type mistake but that the current version of Elixir wouldn't catch as a
>> warning or error.
>>
>> One case I found is something a programmer probably wouldn't do
>> intentionally, and could be worth warning about.
>>
>> Currently, you can name a varaible as a built-in type, for example this
>> is correct code:
>>
>> # Set the variable named "integer" to the string "42". Despite its name
>> it is a string.
>> integer = "42"
>>
>> # This is now valid:
>> # Define a map with string keys
>> profile = %{
>> "age" => integer,
>> }
>>
>> # Access data from the map
>> age = profile["age"]
>> IO.puts("Age: #{age}")
>>
>> Try it. It will print:
>> iex(9)> IO.puts("Age: #{age}")
>> Age: 42
>> :ok
>>
>> It's a string all along and someone might wonder why they're seeing
>> bizarre code like that, but as more types got introduced it would be more
>> likely that programmers learning the syntax would *accidentally* name a
>> variable by the name of a type. Polymorphic code could eventually lead to
>> tricky issues.
>>
>> What I think should happen is that the line:
>>
>> integer = "42"
>>
>> should warn:
>>
>> Warning: variable named with the name a type. This is probably not what
>> you want. Consider changing the name of a variable so that it is not also
>> the name of a type, for example rather than
>> integer = "42"
>> you could name it:
>> my_string = "42"
>> In this case "my_string" is no longer the name of a type.
>> "
>>
>> What do you think about this proposed warning?
>>
>> 1. Do you think anyone would purposefully name a variable a type? (false
>> positives.)
>> 2. Do you think it could be useful for catching future syntax errors,
>> especially as the type system becomes more fleshed-out and there is more
>> polymorphic code? (true positives)
>>
>> The warning could also be useful once more types are used in the future.
>> A local variable should not accidentally shadow the name of a type without
>> warning.
>>
>> This warning can be added to the current version of Elixir and does not
>> depend on gradual typing.
>>
>> Best regards,
>> Rob
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/5f713616-b9e8-4ad5-b2eb-6a51327c8bf4n%40googlegroups.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/5f713616-b9e8-4ad5-b2eb-6a51327c8bf4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BLp0Pn6atjB1RRxap4Ww%2BdookYqJPyM%2BZvy_ng2Dve6Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BLp0Pn6atjB1RRxap4Ww%2BdookYqJPyM%2BZvy_ng2Dve6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAFwChB%3Dg85M-K8jR5pjrRsv%2ByoQh6fuh97JA1r%3DaSMW1LGQqWw%40mail.gmail.com.
