Possible @property compromise

[Zach the Mystic]

On Friday, 1 February 2013 at 16:24:53 UTC, Michel Fortin wrote:
> On 2013-02-01 15:54:14 +0000, "Zach the Mystic" 
> <reachBUTMINUSTHISzach at gOOGLYmail.com> said:
>
>> And there is simply no need for a data-less struct to allow a 
>> "this" pointer. There will never be any need to know the 
>> address of a data-less struct. Any use of it will simply give: 
>> "Error: a struct with no data may not contain a 'this' 
>> pointer". And any use requiring taking its address is 
>> statically disallowed at compile time. This is not a hard 
>> feature to implement.
>
> I think what Steven is saying is that you're distorting the 
> concept of a struct beyond recognition.

Yes, this is exactly what I am trying to do, because it's yet 
another totally badass thing to do. But I'm simply adding it to 
D's list of such things - CTFE, enums as manifest constants(?), 
the reuse of keyword static all over the place, strings as 
immutables. Am I wrong?

> What you really want/need is just some kind of namespace inside 
> the outer scope.
>
> Note that D almost has what you want already if you do it 
> through a template mixin:
> http://www.digitalmars.com/d/archives/digitalmars/D/properties_using_template_mixins_and_alias_this_87952.html
>
> The only thing missing is opGet or an equivalent, and probably 
> a more straightforward syntax. And perhaps someone should check 
> whether the functions can be made virtual too (another 
> requirement that doesn't really belong in a struct).

That's why it's so weird to see people suggesting so many ideas 
for @property, when this functionality is basically already built 
into the language. My suggestion already works at module level. 
Look:

import std.traits;

Front front;
struct Front
{
   ref T opCall(T)(T[] a)
   if (!isNarrowString!(T[]) && !is(T[] == void[]))
   {
       assert(a.length, "Attempting to fetch the front of an empty
array of " ~ typeof(a[0]).stringof);
       return a[0];
   }
}

int main(string[] args)
{

    assert([1,2,3].front == 1);
    return 0;
}

It needs three improvements:
1) allow it to work everywhere, not just module level
2) make it look good with a new friendly syntax, which by the way 
I'm more proud of than any other suggestions I've made here
3) optimize away the unnecessary hidden pointers