Restriction on annotation values to anydata

[hasithaa]

The Spec says,

ballerina-spec/lang/spec.html

Lines 5190 to 5193 in 0d4003e

	The type-descriptor specifies the type of the annotation tag. The type must be a
	subtype of one of the following three types: <code>true</code>,
	<code>map&lt;anydata></code>, <code>map&lt;anydata>[]</code>. If the
	type-descriptor is omitted, then the type is <code>true</code>.

But in the implementation, some annotations use function pointers values. (e.g: In the ballerina/transaction module)

To allow this, we have to use any instead of anydata. But that leads to other problems like

• We can't freeze an annotation value.
• Source/Const semantics might not work with any type.

[jclark]

I think it would be very problematic to allow function values to be part of annotations (and thus type descriptors), given that they are mutable (because of closures and arguably references to module state).

Maybe it would be sufficient to be able to refer to the module-level name of a function. Other annotations refer to names of variables and parameters.

[jclark]

It might be possible to make compile time const function values work, which would effectively restrict them to names of module-level functions.

[hasithaa]

Maybe it would be sufficient to be able to refer to the module-level name of a function.

Above works, but if annotation developer wants to type check an annotation value, he has to write compiler extension.

It might be possible to make compile-time const function values work, which would effectively restrict them to names of module-level functions.

If we allow compile-time const function in an annotation value, it is no longer an anydata. Isn't it? Then we can't freeze an annotation value.

[jclark]

@hasithaa Frozen mappings and other containers can contain inherently immutable values, even if they are not anydata. So it is not impossible to extend compile-time consts to include things that are inherently immutable. Values of compile-time consts are constrained both by what type we say they must have and by the kinds of expression we allow in compile-time consts. So we could support this by allowing variable-references in compile-time consts to refer to module-level functions, and by loosening the constraint on the type that compile-time consts must have. This raises the question of what exactly immutable means, and does it make sense to consider some (e.g. module level functions) or all functions as immutable.

[jclark]

This can be addressed as part of #189

[jclark]

We can make the type be anydata|readonly as for error detail record fields, using #462.