Possible @property compromise

[Steven Schveighoffer]

On Fri, 01 Feb 2013 12:27:58 -0500, Zach the Mystic  
<reachBUTMINUSTHISzach at googlymail.com> wrote:

> On Friday, 1 February 2013 at 16:24:53 UTC, Michel Fortin wrote:
>> 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?

I think you are wrong in how you assume a struct works, but not in your  
attempt to implement properties.  Struct is just not a key to this formula.

Note that many (including myself) consider the overloading of static to be  
a *detriment*.

>
>> 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

You are applying struct where none is needed.

The current front accomplishes what you have shown except it does not  
require an actual struct instance (as your code does), and it's far easier  
to understand and implement than your method.

What you are trying to do is establish a *namespace* in which to declare  
operator overloads.  The whole idea that it has to be a struct is  
incorrect, it does not need a "struct" wrapper.

I think you are not understanding how a struct is implemented, and how  
it's methods are implemented.  A struct function without a 'this'  
reference is a static struct function.  Nothing different from a standard  
function, except it is in the struct *namespace*.  I think this is what  
you really are after, a separate *namespace*.

I think *that* idea has merit, and should be examined.  Drop the struct,  
and you are back to the table.

-Steve