[eeps] Proposal for -type_assert

[Michael Truog]

On 07/14/2014 02:50 PM, Michael Truog wrote:
> On 07/14/2014 02:32 PM, Siraaj Khandkar wrote:
>> Correct me if I misunderstand you, but it sounds like you're pointing to
>> the fact that success typing can only analyze the success of something
>> that has been called, so an interface of a library module would not be
>> analyzed on its own, but only as part of some other code that uses it
>> (and only the used functions at that). Yes?
> Not exactly, by a function that is private I mean functions that I would be forced to use "-compile({nowarn_unused_function, [...])" with so that only their -spec usage is significant and the lack of any real use of the function doesn't cause the compiler to create warnings.  That approach may work as a convoluted type assertion but the extra source code required while not being straight-forward for source code reading makes this dirty IMO.
>
> Part of the reason I think this requires a "-type_assert" is because I see the problem as a preprocessing problem to be handled along with other type creation.
>
>>
>> Calling those library functions by some private functions is called
>> testing and there's nothing dirty about it :)
>>
>>
>> On 07/14/2014 04:49 PM, Michael Truog wrote:
>>> I am wondering if there is any support for adding a simple type
>>> assertion to the Erlang syntax.  The statement would be with
>>> "-type_assert" and it would have the same syntax as "-type" but would be
>>> asserting the developer's assumption of what the type should be.  I am
>>> finding this functionality necessary outside of normal -spec usage
>>> (which can help to provide some assertions when used with dialyzer)
>>> because of generic source code making assumptions that are only
>>> eventually required at lower layers, later in the execution during
>>> runtime, not during the initialization, which means that I can not
>>> easily put the assertion into a -spec unless I use functions that are
>>> private and not called (a dirty trick).  The "-type_assert" would be
>>> able to catch type errors at compile time which also helps to eliminate
>>> problems earlier on, avoiding the longer execution time required for
>>> dialyzer to process everything, so this also helps to speed up normal
>>> development tasks.  Any thoughts on th
>>> is?
>>>
>
Let me clarify this suggestion.  As mentioned by others on IRC (Anthony Ramine), it can't be done at compile-time and must involve changes to dialyzer.  A concrete example is:
-type_assert httpc:method() :: head | get | put | post | trace | options | delete.
To make sure the source code breaks (in a dialyzer run) if httpc:method() changes to be something like "head | get | put | post | trace | options | delete | string()" to support custom methods (valid in HTTP).  This could be done with a -spec but it would be nice to only focus on a single type and not have extra noise with all the other arguments which would be a concern with a -spec.