[Feature request] Support more of pure value type constants

[dsaf]

The sample below is showing an aspect-oriented scenario, but of course there are other scenarios that would benefit.

It would be less error-prone and more developer-friendly to be able to write this (this specific attribute is just a sample):

public const DateTime Millenium = new DateTime(1, 1, 2015);

[DefaultValue(Millenium)]
public DateTime StartDate { get; set; }

...instead of this:

public const string MilleniumStr = "2000-01-01T00:00:00.00000000+00:00";

[DefaultValue(typeof(DateTime), MilleniumStr]
public DateTime StartDate { get; set; }

It is possible to declare a custom attribute constructor that accepts a DateTime, surely it should be possible to use it as well?

This request might be related to #2209 and will improve the #953 usability along with #2319.

[HaloFour]

As I mentioned in the other thread I'm fairly sure that this would involve CLR support. Custom attribute parameters are limited by the runtime to a select few types for simple and predictable serialization/deserialization as the runtime is what is responsible for actually loading the attribute blob and instantiating the class. That list of data types contains the integral types (byte, short, int, etc.), char, bool, enum, string, Type (which is serialized as a string of the type's name) or arrays of any of the previous.

Interestingly enough there are some cases of types being allowed for use in constants but not as literals in custom attributes. They generally involve some compiler trickery. decimal is one of them:

public class Foo {
    public const decimal VALUE = 123.456m;
}

That is turned by the compiler into the following:

public class Foo {
    [System.Runtime.CompilerServices.DecimalConstantAttribute(3, 0, 0, 0, 123456)]
    public static readonly decimal VALUE;

    static Foo {
        VALUE = new System.Decimal(123456, 0, 0, false, 3);
    }
}

[dsaf]

@HaloFour

It seems there is also a DateTimeConstantAttribute inheriting from public abstract CustomConstantAttribute.

I think it is used by VB.NET which unfairly already supports const DateTime:

https://msdn.microsoft.com/en-us/library/dzy06xhf.aspx

[HaloFour]

So C# should be able to support some forms of System. DateTime
"constants" at least, but that still leaves the custom attribute limitation.
On Apr 30, 2015 8:33 AM, "dsaf" notifications@github.com wrote:

@HaloFour https://github.com/HaloFour

It seems there is also a DateTimeConstantAttribute
https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.datetimeconstantattribute(v=vs.110).aspx
inheriting from public abstract CustomConstantAttribute
https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.customconstantattribute(v=vs.110).aspx
.

I think it is used by VB.NET which unfairly already supports const
DateTime:

https://msdn.microsoft.com/en-us/library/dzy06xhf.aspx

—
Reply to this email directly or view it on GitHub
#2401 (comment).

[dsaf]

Is it a duplicate of a semi-Closed #263 in a way? It seems that the team is at least not opposed to the idea.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.