-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usage of typeParams in xml langlib functions #1319
Comments
What are you suggesting it be modified to? |
Both myself and @heshanpadmasiri had a discussion on this and what we thought was about was the following three options.
public isolated function forEach(xml<ItemType> x, @isolatedParam function(ItemType item) returns ()|function(Element|Comment|ProcessingInstruction|Text item) returns () func)
Out of these I think the first one is the better option. |
I'm still not sure I understand why this is invalid: xml b = xml `<a/><b/>`;
// Based on the spec this shouldn't work because the `ItemType` is not an upper bound `xml`
b.forEach(function (xml e) {
}); Let's define type X function(Element|Comment|ProcessingInstruction|Text item) returns ();
type Y function (xml item) returns (); If we instantiate the type of Am I confused? |
Here the function is passed a parameter of type @typeParam
type ItemType Element|Comment|ProcessingInstruction|Text; When a parameter is marked as a typeParam it defines an upper bound for the type that can be passed to that. Here |
Description:
Based on the spec, the type defined by the
typeParam
is defined to be an upper bound on the type parameter.In the case of
xml
consider the followingforEach
function definition.Where the
ItemType
is defined as,The second parameter
func
in theforEach
function defines a function which accepts parameteritem
of typeItemType
.Consider following examples,
With the definition of typeParam and the forEach function in the spec second case is invalid. This is because the in the second case the ItemType is not an upper bound for
xml
. This worked so far in the compiler due to a bug. Shouldn't the definition in the spec be modified to support this case as well?Suggested Labels:
Code sample that shows issue:
Related Issues:
The text was updated successfully, but these errors were encountered: