I went ahead and amended my commit and forced the push.  So if you refetch it should include the export declaration now.<div><br></div><div>Richard, I think specifying it as [property()] makes more sense because [any()] is just a list, and at that point why are you using a proplist?  Said another way, if the type was [any()] then I don't really see much of a benefit of typing it at all.</div>
<div><br></div><div>-Ryan<br><br><div class="gmail_quote">On Mon, May 23, 2011 at 11:36 AM, Richard Carlsson <span dir="ltr"><<a href="mailto:carlsson.richard@gmail.com">carlsson.richard@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 2011-05-23 17:00, Ryan Zezeski wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I found it odd the there is no canonical proplist() type defined so this<br>
is my attempt at adding one.<br>
<br>
git fetch git://<a href="http://github.com/rzezeski/otp.git" target="_blank">github.com/rzezeski/otp.git</a><br></div>
<<a href="http://github.com/rzezeski/otp.git" target="_blank">http://github.com/rzezeski/otp.git</a>> add_proplist_type<br>
</blockquote>
<br>
Good idea. It fixes a few overspecified local definitions which state that a proplist has the type [{atom(),term()}] while the proplists module define it to be [property()] where property() = atom() | tuple().<br>
<br>
(If some of those local definitions really mean that only {atom(), term()} are allowed, and they don't actually use the proplists module, they should preferably change the name of their local type instead.)<br>
<br>
A couple of examples should make it clear: to the proplists module, all of these elements are valid properties:<br>
<br>
    foo                  % interpreted as equal to {foo, true}<br>
    {bar, 42}<br>
    {<<"baz">>, 1234}    % the key can be any term, not just an atom<br>
    {foo, 1, 2, 3}       % the tuple may have more than two elements<br>
    {foo}                % even a tuple with only a key is allowed<br>
<br>
In fact, the functions in the proplists module generally allow other terms to be present in the list, so they actually accept [any()] as input, but elements that are not of the property() type are ignored.<br>
Specifying that they require [property()] instead might concievably make some existing code be considered as broken by Dialyzer, but it could be worth it in order to get better checking in normal cases. I'll leave this decision to Kostis and the OTP team.<br>

<br>
    /Richard<br>
_______________________________________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
</blockquote></div><br></div>