[eeps] Proposal for -type_assert

[Michael Truog]

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?
>>