[erlang-questions] Temporarily violating record type constraints annoys dialyzer

[Dániel Szoboszlay]

I agree that the warn_untyped_record warning does exactly what its name
suggests.

However, when working with records without types, a different warning would
be useful, something that could be called maybe warn_untyped_record_in_type and
what would give you a warning when a -type or -spec declaration contains a
record without type specification for all of its fields.

For example:
-record(foo, {a :: integer(), b}).
-type a() :: #foo{b :: boolean()}. % this is OK, both fields of #foo have a
type
-type b() :: #foo{}.               % this is wrong, #foo.b has no explicit
type

Daniel

On Fri, 7 Dec 2018 at 15:39 Kostis Sagonas <kostis@REDACTED> wrote:

> On 12/7/18 3:06 PM, Boroska András wrote:
> > Sorry, I meant bug report on the _compiler_ (not on dialyzer).
> >
> > On Fri, Dec 7, 2018 at 3:04 PM Boroska András <andras.boroska@REDACTED
> > <mailto:andras.boroska@REDACTED>> wrote:
> >
> >     Hi,
> >
> >     When defining records the way Daniel suggests dialyzer seems to find
> >     problems with record field constraints better. I find it helpful and
> >     changed our record definitions everywhere.
> >
> >     On the other hand when 'warn_untyped_record' compiler option is
> >     turned on, it warns us that "record foo has field(s) without type
> >     information". (OTP-21.1.3) Shall I open a bug report/feature request
> >     on dialyzer?
>
> If, for whatever reason, you find that having records without types
> works better for your setting / code base, what's the reason why you
> also set the `warn_untyped_record' compiler option?
>
> It's off by default, isn't it?  (And its name explicitly suggests that
> it warns when you have record definitions without types, doesn't it?)
>
> Kostis
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20181207/09e49d34/attachment.htm>