A common scenario in development is to have fields or types to exist depending on constants set on the environment, usually Release and Debug environments.
This proposal is for a scope keyword, to work as a generic form of first class support for this case.
The scope will have the format of:
scope $(ConditionList)
{
$(Contents)
}
The ConditionList is a comma separated list of Condition expressions. Each Condition will be a string Tag with an optional ! to negate it. Will other operations be useful?
Example:
scope (Network, !Debug)
{
}
To ease iteration on the files, a empty list, or maybe even skipping the list at all will be supported. In this case it will be as if there is no scope at all. Example: scope () { } or scope { }
The Contents is either one or more struct definitions, or one or more field definitions.
Ommiting the {}scope block delimiters for single items can be considered, example:
scope (Network, !Debug)
def struct Foo
{
}
But this feature is likely to increase parsing complexities.
A common scenario in development is to have fields or types to exist depending on constants set on the environment, usually Release and Debug environments.
This proposal is for a
scopekeyword, to work as a generic form of first class support for this case.The
scopewill have the format of:The
ConditionListis a comma separated list ofConditionexpressions. EachConditionwill be a stringTagwith an optional!to negate it. Will other operations be useful? Example:To ease iteration on the files, a empty list, or maybe even skipping the list at all will be supported. In this case it will be as if there is no scope at all. Example:
scope () { }orscope { }The
Contentsis either one or more struct definitions, or one or more field definitions. Ommiting the{}scopeblock delimiters for single items can be considered, example:But this feature is likely to increase parsing complexities.