The issue with an attribute is everyone immediately preferred this at the
call site which looks pretty awkward for attributes eg
1) Why does the writer of the caller need to know , shouldn't the
compiler be able to work that out .
2) Some of these attributes get pretty big ( eg serialization , IOC ).
Im not qualified to give an answer.. but I can observe that its very
annoying in C# ( the black magic we discussed ) of having stack created
value types , then passing them by ref and out and the system occasionally
boxing them eg to do a vcall on an interface or because there is a reference
from the heap. Obviously when the language was designed it was just Value
Types and Reference Types ( with ref intended to be used rarely which it
is) but people pushed the Value types by ref , way passed the intended use .
Would it be possible to say for these types to mark them with say
[StackAlloc] [ByRef] , then the function calls always pass them that way
meaning we don't need it on the function syntax in the rare ( and bad)
case where you want to pass a value type by ref just get the dev to convert
it . Or maybe better use 3 types basetype ( value type by value) ,
struct ( stack by ref) and class ( heap by ref) for data, this will make
it easier dealing with issues such as a class pointer to a stack struct (
either illegal or auto convert to a basetype) etc .
The other big issue is to something like this
read( IMessage ref message) { if (message is AllocMessage ) .breakout
method } in C# its impossible to do without boxing forcing something
like parsing a pointer casting it as a type , checking a type field and
then casting the data etc . Yet unless you call a virt method it should be
possible ( if the type is stored with a struct maybe with an [IncludeType]
attribute) .
Anyway I'm way passed my comfort zone so will go back to my corner and let
you get something out, would love to play with BitC for my Async IPC
prototyping J
Ben
That's a really good question -- particularly so because attributes that are
part of the standard library are free to be interpreted by the compiler and
can have defined interpretations. So the answer might well want to be "yes".
That said, these particular effects definitely are part of the language, no
matter how they are encoded for convenience.
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
