[nem-en] Nullable types

[Kamil Skalski]

>
> DataAdapter fills in a DataTable and you have to know that DataTable
> stores all of its values as boxed ValueTypes (or Objects). So there will
> be no Nullable<> conversion.
> I looked at DataReader and it is a shame that MS missed something
> so plausible (from an MS employee):

Yes, so answer to my thoughts is just "no" ;)  I will live with this,
but it requires some more care...

>
> BTW I would vote for a Nemerle extension, eg naming types as ?typename
> or typename?. This would simply mean a shortcut to Nullable.[typename].
> Where is that dot? :)

This patch adds it:
Index: macros/core.n
===================================================================
--- macros/core.n       (revision 6057)
+++ macros/core.n       (working copy)
@@ -38,6 +38,7 @@
 [assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core", "is",
false, 210, 211)]
 [assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core", ".",
false, 285, 301)]
 [assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core", "++",
true, 283, 284)]
+[assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core", "?",
true, 283, 284)]
 [assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core", "--",
true, 283, 284)]
 [assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core",
"where", false, 284, 300)]
 [assembly: Nemerle.Internal.OperatorAttribute ("Nemerle.Core", "/",
false, 260, 261)]
Index: ncc/typing/TyVarEnv.n
===================================================================
--- ncc/typing/TyVarEnv.n       (revision 6057)
+++ ncc/typing/TyVarEnv.n       (working copy)
@@ -272,6 +272,8 @@
           | <[ this ]> =>
             curtc.GetMemType ()

+          | <[ @? ($t) ]> => f2 (<[ System.Nullable [$t] ]>,
allow_ref)
+
           | PExpr.Void => InternalType.Void

           | PExpr.Indexer


But still it is far from usefulness, for example:
def f (x : int?) {
  Nemerle.IO.print ("bla $x blu\n");
}
f (System.Nullable (1));
f (System.Nullable ());

works and prints
bla 1 blu
bla  blu

but more interesting examples:

 f (1);  // does not work... maybe a problem with implicit operator
 f (null); // does not work.. we need special handling by compiler

My guess it that at least the first one should work, because there is
implicit operator converting T to T? in System.Nullable. Second one
(and a few others) need special handling in compiler. Especially, that
they often emit calls to some special methods or properties.

> Ehh, probable we should fix the generics notation as ALWAYS requiring
> the extra dot. You can see in the D "specification" that they use
> templatename!(templateparam1, ...) as a template instantiation... (I
> myself does not think that D will take off...)

No no! Optionally you could resign from the .[] notation at all. It is
rarely used, because compiler can infer the types by itself. You
should not see this syntax in a real code, unless you are doing some
really generics fat code.



--
Kamil Skalski
http://nazgul.omega.pl