You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Redundant or conflicting totality modifiers do not explain why they are a problem and to not provide the user with a path toward resolution.
No error, redundant but unique modifier
module M
covering
fn: String
This is fine, although the modifier is redundant because files are covering by default it makes clear the intent that this function is meant to be covering, even if the default modifier changes.
No error, different and unique modifier
module M
%defaulttotal
covering
fn: String
This is expected, the function fn does not follow the default and needs a bespoke modifier.
Error: incompatible modifier
module M
covering totalfn: a
This is an error since there is no way to know what modifier the user intended for this program. The solutions for it should be to:
remove covering
remove total
remove both
Error: duplicate modifier
module M
covering covering
fn: String
This is an error. There is no reason to put the modifier twice, and changing only one of them will result in an error. In this case, we should as the user to either:
remove one covering
remove both covering since the default is covering
Conclusion
The appropriate error messages should also be adapted when the default is not covering
The text was updated successfully, but these errors were encountered:
Another case is forward declarations of data and records, conflicting declarations should be disallowed.
covering
dataFoo:Type
total
data Foo : Typewhere
But leaving it off of the second one should be allowed:
covering
dataFoo:Type
data Foo : Typewhere
This behavior is consistent with the way public export vs export are handled today:
public export
dataFoo:Type
export
data Foo : Typewhere
gives a warning:
1/1: Building Foo (Foo.idr)
Warning: Main.Foo has been forward-declared with public export visibility, cannot change to export. This will be an error in a later release.
Follow up from #3441 :
Redundant or conflicting totality modifiers do not explain why they are a problem and to not provide the user with a path toward resolution.
No error, redundant but unique modifier
This is fine, although the modifier is redundant because files are
covering
by default it makes clear the intent that this function is meant to be covering, even if the default modifier changes.No error, different and unique modifier
This is expected, the function
fn
does not follow the default and needs a bespoke modifier.Error: incompatible modifier
This is an error since there is no way to know what modifier the user intended for this program. The solutions for it should be to:
covering
total
Error: duplicate modifier
This is an error. There is no reason to put the modifier twice, and changing only one of them will result in an error. In this case, we should as the user to either:
covering
covering
since the default iscovering
Conclusion
The appropriate error messages should also be adapted when the default is not
covering
The text was updated successfully, but these errors were encountered: