Type Specification of net:getnameinfo()

[Nalin Ranjan]

For this particular function its a delegation to prim_net:getnameinfo/2
<https://github.com/erlang/otp/blob/master/erts/preloaded/src/prim_net.erl#L160>
or erlang:error(notsup). Of course, apart from some argument match.

Interesting.

And Micael mentioned its destined to be removed in future. ��

नमस्ते।
नलिन रंजन

On Wed, Jan 27, 2021 at 9:13 AM Nalin Ranjan <ranjanified@REDACTED> wrote:

> Thanks a lot Nicolas.
>
> Will go through, and then may be express my hunch that this is a way in
> which details are either leaking and/or is not sufficient at the level of a
> type spec. But who knows I endup correcting myself after a little follow up.
>
> नमस्ते।
> नलिन रंजन
>
> On Tue, Jan 26, 2021, 10:05 PM Nicolas Martyanoff <khaelin@REDACTED>
> wrote:
>
>> On 2021-01-26 21:46, Nalin Ranjan wrote:
>> > 2. In this particular case of type specification, the only difference
>> is in
>> > one of the parameters of the function. I was also wondering if we could
>> > have used a union instead to write the same type spec, it would have
>> been
>> > simpler?
>> > For example,
>> > Instead of writing a type spec like this
>> >
>> > -ifdef(SOME_PRAGMA_CONDITION)
>> >           SomeVar :: xxx_type().
>> > -else
>> >          SomeVar :: yyy_type().
>> >
>> > We could specify the same type spec as:
>> >         SomeVar :: xxx_type() | yyy_type().
>> >
>> > Any reason we preferred the former over the latter?
>>
>> If Erlang is compiled without socket support, some types will not exist at
>> all. Using the preprocessor[1] makes it possible to provide specifications
>> with types which actually exist, with or without socket support.
>>
>> [1] https://erlang.org/doc/reference_manual/macros.html
>>
>> --
>> Nicolas Martyanoff
>> http://snowsyn.net
>> khaelin@REDACTED
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210127/4e71332b/attachment.htm>