On Friday, 1 February 2013 at 16:24:53 UTC, Michel Fortin wrote:
On 2013-02-01 15:54:14 +0000, "Zach the Mystic"
<[email protected]> 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
