Possible @property compromise

Era Scarecrow rtcvb32 at yahoo.com
Wed Jan 30 15:49:53 PST 2013


On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis 
wrote:
> 1. Make it possible to Mark a variable such that you can't do 
> anything with it that you couldn't do with a property function 
> (e.g. taking its address needs to be illegal).

  If we didn't have to interface with C and we were willing to get 
a little extra processing in order to use flags you could get 
away with this. In a 64Bit environment it seems plausible.

  I don't see this as an option realistically with everything as 
it is, however the potential can't be ignored.

  Let's say the top 4 bits of a pointer are flags, one for 'is 
stack' and one for 'is function ptr', etc. The function pointer 
referenced then then make properties work exactly like variables.

  Mind you likely a few extra flags may be needed to determine 
constness for safety, or two ptrs for a getter/setter (or just a 
small lookup table for a combination of them all).

  If these flags then are used and recognize that it has a 
function instead of a variable, it can call the function, however 
passing to C or anything expecting a variable then it would have 
to throw an error as there's no way for the D specific flags to 
be carried over and used safely.

   struct S {
     int _a;
     int a() {return a + 1;}
     int a(int setA) { _a = setA; return setA; }
   }

   Now:

   void func(ref int a) {
     a = 100;
     //real int always passes
     assert(a == 100);
     //can't assume true with function property pointer
   }

   S s;

   //passes, flag realizes it's a function that now is
   //treated as a variable for this purpose.
   func(s.a);

   extern(C) void cFunction(int *ptr);

   //fails, C unaware of handling function reference
   cFunction(s.a);
   //fails, same reason.
   cFunction(&s.a);

  Perhaps it's a small option that in compiling these flags can be 
made use of; Instantiation of templates the properties can be 
treated as variables correctly (invisibly), assuming it never 
passes a reference to anything it can't verify can handle it.

  But as before, this is just an idea, which won't be used in D.


More information about the Digitalmars-d mailing list