Constant disambiguate
Motivation and Context
Currently type propagation through constructors fails such as ["tz1..."] as list<address>
, by supporting patterns almost all disambiguation can happen at the let
level.
Description
The current behavior happens because Ligo uses a try-based unification mechanism relying strictly in infer
and subtype
to find the desirable type, as such the expected type is never propagated to the content.
BUT, because Ligo supports implicit coercion, not all overloaded functions can be safely propagated, as such this only makes a different for a couple functions, namely the ones that are parametric or lack any interaction with implicit coercion.
Component
-
compiler -
website -
webide -
vscode-plugin -
debugger
Types of changes
-
Bug fix (non-breaking change which fixes an issue) -
New feature (non-breaking change which adds functionality) -
Breaking change (fix or feature that would cause existing functionality to not work as expected) -
Performance improvement (non-breaking change that improves performance) -
None (change with no changelog)
Changelog
Checklist:
-
If a new syntax has been introduced, put a message on slack ligo-lsp -
Changes follow the existing coding style (use dune @fmt
to check). -
Tests for the changes have been added (for bug fixes / feature). -
Documentation has been updated. -
Changelog description has been added (if appropriate). -
Start titles under ## Changelog
section with #### (if appropriate). -
There is no image or uploaded file in changelog -
Examples in changed behaviour have been added to the changelog (for breaking change / feature).
Edited by Eduardo RFS