This is a problem with the expressivity of variant types at the DAML-LF level, since there's no distinction between "variant constructor with no inputs" and "variant constructor with a single input of unit type" at the DAML-LF level, as is documented in the official docs.

Perhaps it would be best to pick the other default in data-dependencies? I.e. to translate all "variant constructor with a single input of unit type" into "variant constructor with no inputs". Either way, one of these two will always be translated back into DAML incorrectly in data-dependencies, unless we change something more fundamental about how types are translated into DAML-LF or represented on the ledger API.

This would be a breaking change for existing projects that rely on data-dependencies.

cc @bame-da

If you changed the behaviour in a new DAML-LF version (eg 1.9) so that data-dependencies of LF >= 1.9 packages behaved properly by distinguishing the two cases, think this could be called a bug-fix. Despite being documented, the behaviour @jberthold-da is observing looks sufficiently buggy/broken, and the case where this would affect anyone (recompiling to a new LF version and then using that as a data-dependency) is sufficiently unlikely.

I agree this behaviour is not ideal, but I do not think we should complexity LF. LF variants are unary, making the argument of a variant optional is almost as complex as making them n-nary.

Ok, so, after looking into this and talking with @remyhaemmerle-da, it looks like we could change the way we're compiling variants, so that "variant constructors of no input" end up as synthetic variant-record constructors where the record has no fields. We should gate this change by LF version at least, since it's going to affect people who currently use data-dependencies or the ledger api.

(That all said, multi-package projects with access to the original source code should not rely on data-dependencies when possible, since it's at best an approximation of the original types.)

(That all said, multi-package projects with access to the original source code should not rely on data-dependencies when possible, since it's at best an approximation of the original types.)

But obviously we need to data-dependencies when data needs to migrate during an upgrade to a newer SDK version, or not?

synthetic variant-record constructors where the record has no fields

But that would still require a trailing {} as an argument to the constructor in the above, or am I missing something?

But obviously we need to data-dependencies when data needs to migrate during an upgrade to a newer SDK version, or not?

Yes, you're right. There should be an effort to minimize how much goes in data-dependencies (vs. dependencies), but type definitions usually need to be in data-dependencies, so my point wasn't very relevant. Sorry for bringing it up.

synthetic variant-record constructors where the record has no fields

But that would still require a trailing {} as an argument to the constructor in the above, or am I missing something?

No, I don't think so. When a constructor has no arguments, V2 and V2 {} are the same as far as GHC is concerned. But we can also take care to translate a synthetic variant-record constructor with no fields in DAML-LF back into an empty variant constructor in DAML, so it's not going to be a problem.

As a workaround for now, you can actually use V2 {} for pattern matching, which will ignore all arguments to the constructor. So this should work in both cases:

f : AVariant -> Text
f x = case x of
         V1 i -> "V1"
         V2 {} -> "V2"

As a workaround for now, you can actually use V2 {} for pattern matching, which will ignore all arguments to the constructor. So this should work in both cases:
V2 {} -> "V2"

That works for the match, thanks. The problem reaches further, though, I also want to construct values using V2 and am hitting the same issue.
For my use case I can just insert the units (as I know the constructor lives in a different package) and remove that later when the compiler is fixed.

Maybe worthwhile to note: The change of arity of this constructor only happens when the original package is depended upon as a data dependency. When using a full dependency the constructor match and value without argument compiles fine.

Maybe worthwhile to note: The change of arity of this constructor only happens when the original package is depended upon as a data dependency. When using a full dependency the constructor match and value without argument compiles fine.

Yes, this is expected. "dependencies" use GHC's built-in mechanism (interface files) so you have all information from the original package, whereas "data-dependencies" go back from built DALF files, and try to provide a DAML interface to LF code by adding stubs. It is at best an approximation of the original interface, and should, at this point, be thought of as something similar to using the ledger API or language bindings.

Ok, so, after looking into this and talking with @remyhaemmerle-da, it looks like we could change the way we're compiling variants, so that "variant constructors of no input" end up as synthetic variant-record constructors where the record has no fields. We should gate this change by LF version at least, since it's going to affect people who currently use data-dependencies or the ledger api.

I've been implementing this and it looks like a bigger change than I thought, and wouldn't be surprised if it broke a lot of existing code. I would be a lot more comfortable with my first proposed solution -- to change the default way of translating DAML-LF variants with unit constructors back into DAML types, so that you get a constructor with no argument instead of a constructor with a unit argument. We could even deprecate variant constructor with unit arguments from DAML, since they have dubious utility, like we did for record types whose constructor name doesn't match the type name (because it doesn't have a representation at the LF level).

cc @hurryabit

I agree with the suggestion to deprecate variant constructors with a single unnamed argument of type (). I would start by showing a warning that explains how you'll get in trouble when using this with data-dependencies and what to use instead.