Using C#-like syntax for dynamic (and other keywords that compile to attributes)

[jnm2]

Would you be interested in showing [System.Runtime.CompilerServices.DynamicAttribute()] object as dynamic, similar to the C# syntax that you'd see in intellisense when interacting with the API?

An argument against it might be that it's better to put lower-level realities in your face in case the API is used from a language where the attribute is not specially-recognized.

Maybe an argument for it would be that it would be consistent with [ParamsAttribute], [ExtensionAttribute], etc, and the same kind of thing with C# 8 attributes: #54

A few other attributes have cropped up like the ones for the C# 7.0 ref and readonly keywords when declaring a struct:

public readonly ref struct Foo
{
}

Desugared:

[IsByRefLike]
[Obsolete("Types with embedded references are not supported in this version of your compiler.", true)]
[IsReadOnly]
public struct Foo
{
}

https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA+ABAzAAlgQwBMIA7AGwE88YAzHAZwBcoBXMRnAMQggFgAoAN4CAvkA=

[danielmarbach]

Dynamic sure but I say we can target that for another release. It seems of lower importance than the other cases you mentioned Rudimentary readonly support for example for structs is in https://github.com/ApiApprover/ApiApprover/pull/84But sure the support is probably not yet superb and could be made better

[jnm2]

Another one is volatile instead of modreq(System.Runtime.CompilerServices.IsVolatile).

[sungam3r]

I have already come across this notation (modreq) in #54.

[sungam3r]

I think that volatile itself is not a part of api. It is just implementation detail.

[sungam3r]

Regarding dynamic: https://sharplab.io/#gist:e22ba1bb9e308621e59bce8eaf95c021

The rabbit hole is quite deep...

[jnm2]

I think that volatile itself is not a part of api. It is just implementation detail.

The modreq indicates how important it is as API. Modreqs are how you can express "this object requires special handling."

If you access a volatile field, the compiler emits a volatile. prefix before the stfld/ldfld instructions. It should show up in a dramatic way in your public API if the volatility changes because it's a breaking change. It's a binary behavioral breaking change because libraries compiled against an older version of your library will not use volatile. when they should, and it's a compile-time break because errors begin showing up if you take a ref to a suddenly-volatile field.

(Happy to open a separate issue though.)

[jnm2]

Regarding dynamic: https://sharplab.io/#gist:e22ba1bb9e308621e59bce8eaf95c021

The rabbit hole is quite deep...

Wow, I didn't know that's how it was encoded! 😬

Btw, your sharplab links have been missing #nullable enable.

[sungam3r]

Let's open another issue for volatile.

[sungam3r]

Volatile fix seems to be more simple than dynamic.

[jnm2]

#116

[stakx]

Regarding dynamic: https://sharplab.io/#gist:e22ba1bb9e308621e59bce8eaf95c021

The rabbit hole is quite deep...

@sungam3r that code snippet appears to be gone; any chance that you could restore or repost it?

[sungam3r]

Unfortunately, I don't remember anything about dynamic gist at all. Perhaps the point is that dynamic is encoded in a special way, something like NRT: https://sharplab.io/#gist:a135eb77630b190590b751c7af429743