Hi, I’m trying to get hang of specs, but I’ve hit a wall. I’m writing a thin facade over Nerves’ SystemRegistry, basically stuff like: defmodule ConfigRegistry do @spec update(SystemRegistry.scope(), any) :: {:ok, {map, map}} | {:error, term} def update(scope, value) do SystemRegistry.upda…

[image] peerreynders: try to corral the problem into a fairly small code sample (8 hours ago: Hmmm, I should probably do that…) This has gotten interesting. First, I’ve reduced the warning-inducing code to this: defmodule WhatTheSpec do @type key :: atom() @type transaction :: map() …

A spec will not actually constrain the input to your update function. If someone calls your function with a Transaction.t for the first parameter, you will invoke the other clause in Nerves. Did you try adding a when clause to your update like when is_list(scope) ?

Thanks for the input. [image] jeremyjh: If someone calls your function with a Transaction.t for the first parameter, you will invoke the other clause in Nerves. I won’t; Note that [:config | scope] is passed to SystemRegistry.update. [image] jeremyjh: Did you try adding a when clause to…

[image] prook: tells me there are two update s, This is where your mental model breaks down: there is only and there can only be one update/3 function. That function may be implemented in terms of multiple function clauses - but they all belong to the same function. The Erlang style of specs …

[image] peerreynders: This is where your mental model breaks down …and I already slapped my forehead. Thank you. :slight_smile:

Tried this approach? def update(scope, value) do case SystemRegistry.update([:config | scope], value) do %SystemRegistry.Transaction{} -> {:error, :undefined} # i.e. this will never happen result -> result end end or even more explicitly, intention revealing …

Pondering the topic some more… There is one SystemRegistry.update/3, but it actually does two very different things, or, better yet, it covers two completely different use cases; One is “do an update (and handle a transaction internally)”, the other is “add this update command to this transaction”. …

[image] peerreynders: So strictly speaking the return type of SystemRegistry.update/3 is the sum type Transaction.t() | {:ok, {new :: map, old :: map}} | {:error, term} . That isn’t the success typing dialyzer is inferring, though.

I wasn’t sure whether the dialyzer error was completely quoted. I wondered whether dialyzer was just complaining about the missing case. … but I can see your point. At least @spec update([any()], _) :: %SystemRegistry.Transaction{ tells us that dialyzer is fully aware that the first argument wi…

Yes my comment was so obviously wrong I didn’t bother to acknowledge it :slight_smile: @prook curious did you track this down?

I’ve resolved Dialyxir’s complaints by replacing SystemRegistry.update([@mount | scope], value) with SystemRegistry.transaction() |> SystemRegistry.update([@mount | scope], value) |> SystemRegistry.commit() This avoids ambiguous SR.update/3 with SR.commit/1, which is specced clearly,…

Confused about spec/dialyxir: "Invalid type specification for function"

Questions & Help Questions

prook September 7, 2018, 4:03pm 5

…and I already slapped my forehead. Thank you.