VB.Net usage of Date type

[mattjohnsonpint]

Since VB has its own Date keyword as part of the language, and this is mapped explicitly to System.DateTime, we need to document what workarounds are required to use System.Date in a VB.Net project.

This assumes no new language changes. It's conceivable at some point in the future that an Option flag could be added to the language to disable the built-in mapping, but for now we'll assume that it doesn't exist.

[mattjohnsonpint]

As I thought... because we define the type as System.Date, it seems to be impossible to use it from VB.Net.

By default Date is treated as System.DateTime due to the language keyword mapping:

Dim d as Date  ' d will be a System.DateTime, not our System.Date

We can escape the keyword:

Dim d as [Date]

But then we get the compiler error:

BC30560: 'Date' is ambiguous in the namespace 'System'.

I can think of two changes that would fix the problem, neither of which I particularly like:

• We could change the type name to something else, suggestions when this was discussed on dotnet/corefx#700 were: CalendarDate, AbsoluteDate, PureDate, LocalDate - none of which are quite as nice as just Date.
• We could place the new types in a different namespace, such as System.DateAndTime or System.Temporal etc.

The option pointed out by @paulirwin of having the VB language get an Option Date Off setting, seems unlikely to me.

Any other ideas?

FWIW - I already explored using Imports statement, with no success. And AFAIK, VB.Net doesn't have anything like c# extern alias, which would solve the problem.

[paulirwin]

Agreed that neither are good options, but of those, I'd vote for using CalendarDate.

[gafter]

You wrote

We can escape the keyword:

Dim d as [Date]

But then we get the compiler error:

BC30560: 'Date' is ambiguous in the namespace 'System'.

I think you did something wrong. That works for me. I suspect you have two different definitions of System.Date among your set of referenced assemblies.

[mattjohnsonpint]

Interestingly, it works just fine when compiled from VS2015, but not when compiled from VS2013.

Did we stumble upon a difference with the Roslyn vs traditional compilers?

I think if it works in 2015, that should be good enough for .NET Core, right?

[mattjohnsonpint]

@gafter - Any idea why [Date] works with VS2015 but not VS2013?

[mattjohnsonpint]

No answer, ok.

Perhaps @ljw1004 might have an idea? Specifically, I'm wondering what's different about the Roslyn-based VB compiler that allows Dim d As [Date] to work with the System.Date type in this library, while the old compiler gets stuck on the Date to System.DateTime alias mapping as a duplicate definition.

Can I count on it continuing to work? Or is it working by accident due to some oversight in the compiler?

Thanks in advance.

[mattjohnsonpint]

See https://github.com/mj1856/corefx-dateandtime/blob/vb/System.DateAndTime.VBTests/VisualBasicUsageTest.vb

[ljw1004]

Roslyn is doing the right thing and you can count in it continuing to work. It's hard to imagine what the VS2013 VB compiler is thinking here.

I don't believe the old compiler gets stuck on Date == System.DateTime alias: for if you remove the reference to your PCL which defines your date class, then the VS2013 VB compiler correctly treats [Date] as an error rather than a successful reference to System.DateTime. My only guess is that maybe the old compiler was being too greedy in some way, to eager to import the type Date as special, and it incorrectly placed it in two different lookup tables.

[mattjohnsonpint]

Cool. Thanks for looking into it. I appreciate your insight!