Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Compile-time error with Nullable DateTime / user Enumeration. #67

duckmaestro opened this Issue · 7 comments

4 participants


I'm receiving a set of compile-time errors when trying to declare DateTime? or MyEnumType? as method parameters.

Example (for one occurrence of public DateTime GetServerTime(DateTime? clientTime) { ... }:

MySourceFile.cs(62,48): Syntax error: 'Identifier' expected
MySourceFile.cs(62,60): Syntax error: ':' expected
MySourceFile.cs(62,48): Syntax error: Expression statement must do work
MySourceFile.cs(62,60): Syntax error: ';' expected

I have a workaround for now (using pre-0.7.x technique). This is just FYI.


I'm having the same problem with 0.7.2. Adding a nullable DateTime field to a class as follows will fail to compile:

DateTime? x;

It results in the following compile errors:

Syntax error: 'Identifier' expected
Syntax error: 'Identifier' expected

Changing to the following allows it compile:

Nullable<DateTime> x;

DateTime should probably not be a value type in script# so it correctly reflects script semantics.


I agree that DateTime should not be a value type in Script#.

Although it is nice to have types in Script# that closely match .NET types, it is more important they accurately reflect their respective types in JavaScript as much as reasonably possible.


One thing I like about Script# is the ability to declare a class in my server side code and add a link to it in my Script# project. This makes it easy when sending data back and forth through web services.

Having to use two classes because Script# won't match c# types would add some unnecessary complexity.


I agree that is an interesting scenario ... however script# was never intended to cater to the cross-compilation/porting scenario, though if you tread carefully, you can get a bit lucky (sometimes) :-)

As Matt Clay mentioned, my first preference would be to honor script semantics, and a date in script doesn't behave like a value type. That said, my hopes of converting DateTime to be a class were squashed, because the c# compiler doesn't like it when I try to compile mscorlib itself.

I might still evaluate some alternative like even call the class Date instead of DateTime (if it works) ... but there are pros/cons to that as well. Pro because it will clearly indicate this class isn't behaving like the DateTime value type you're used to in c#, and con because of deviations from core framework constructs. However there are probably enough differences on the date type that the alignment is superficial ... just at the naming level. For example, I believe month is 0-based in script and 1-based in managed code... or some such difference. In that case, a different name altogether might actually be beneficial, even if painful and a bit annoying.

Thoughts on this debate I'm having in my mind?


Change made. 6e8d805

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.