[gmueckl]

    class Foo {
      public uint Bar { get; set; }

      private char[] _baz;

      public char[] Baz { get { return _baz;} }

      public Foo() { _baz = new char[5]; }
    }

This is cheating a bit on the array part. But the length of that char array is set in stone and cannot be changed from the outside. However, the Bar property uses a standard C# datatype.

[maxxxxx]

I honestly thing that you haven't done any real work with LINQ or you are imagining problems that don't exist. The char array is not usable as string or we have to go back to 0 terminated strings like C.

[gmueckl]

I am not imagining problems that don't exist in the application domains I work on.

If your environment is so relaxed that aspects like signedness of an integer don't matter, so be it. But then you are also far removed from a domain where software correctness is non-negotiable.

[scarface74]

It’s not aspects “like signednes” that’s the only constraint that you could embed in your defined POCO and still use as a select projection that would survive a LINQ expression that was turned into an expression tree. Your data store would enforce the other constraints. Your C style character array as a string wouldn’t work with either LINQ nor any of the standard library.

Are you really trying to go back to the bad old days with Microsoft C/MFC/WIN32/COM where you had over a dozen ways to represent a string that you had to convert to and from depending on which API you were using?

[scarface74]

And your class wouldn’t work as part of the LINQ example. EF for example wouldn’t know how to translate it.