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
I have found the following situations where the 'domain' keyword/typename is not allowed, where I think maybe it should be. All of the following situations result in syntax errors. This can be worked around in all cases by replacing domain with domain(?).
Using a domain in a where clause as a bare typename
proc foo(x) where x.type==domain { } // syntax error near '{'proc bar(x)
where isSubtype(x.type, domain) // syntax error near ')'
{ }
Using a domain in a type expression as a bare typename
type t =domain; // syntax error near ';'
proc foo(type t) dowriteln(t:string);
foo(domain); // syntax error near ')'
record R {
type T;
procinit(type T) dothis.T = T;
}
var x: R(domain); // syntax error near ';'var y =new R(domain); // syntax error near ';'type z = R(domain); // syntax error near ';'
Note that resolving the syntax error for this case by writing domain as domain(?) ends up being a resolution error anyways, but this issue is not about that, just the syntax issues.
Using a domain in a cast
operator:(x:range, type t:domain) doreturn {x};
var d = (1..10):domain; // syntax error near ';'
Compare this with some other typenames. Replacing domain in any of these codes with, for example, range, locale, or imag compiles and works as expected.
type x =range; // valid codevar x =new R(locale); // valid code
foo(imag); // valid code
It is potentially up for debate if we allow this, especially as we move to a world where domain(?) is the preferred way to write a generic domain. So the right thing to do here may be to just make this a better syntax error. But I think the inconsistencies with other keywords/typenames is weird and potentially confusing.
The text was updated successfully, but these errors were encountered:
Readers should note that domain is not a fully-defaulted type like range, locale, and imag are, so I don't think (most of?) these cases should work without additional information (and from your last paragraph, it sounds like you realize this as well). For that reason, it'd be nice if it complained further down the line than the parser, like at the point of saying "I don't know how to cast an x to a generic type" or the "We increasingly require (?) for incomplete generic type specifications" family of warnings. But anything would arguably be an improvement over syntax error including a parser-based specialization of some sort.
I have found the following situations where the 'domain' keyword/typename is not allowed, where I think maybe it should be. All of the following situations result in syntax errors. This can be worked around in all cases by replacing
domain
withdomain(?)
.Using a domain in a where clause as a bare typename
Using a domain in a type expression as a bare typename
Note that resolving the syntax error for this case by writing
domain
asdomain(?)
ends up being a resolution error anyways, but this issue is not about that, just the syntax issues.Using a domain in a cast
Compare this with some other typenames. Replacing
domain
in any of these codes with, for example,range
,locale
, orimag
compiles and works as expected.It is potentially up for debate if we allow this, especially as we move to a world where
domain(?)
is the preferred way to write a generic domain. So the right thing to do here may be to just make this a better syntax error. But I think the inconsistencies with other keywords/typenames is weird and potentially confusing.The text was updated successfully, but these errors were encountered: