On Friday, 1 February 2013 at 01:53:05 UTC, TommiT wrote:
> On Friday, 1 February 2013 at 00:59:47 UTC, Zach the Mystic wrote:
>> writeln(foo.n); // uses alias this to call __mightAsWellBeOpGet
>
> No it won't. It will print "n()".
>
> And that exactly (passing to a templated parameter) is the insurmountable problem in using a variable to represent a property.

I need to study this principle a little more. In other words, alias this is a templated parameter in this case? Which page is the documentation for these templated parameters, because I didn't see templates in my code.

On Friday, 1 February 2013 at 01:53:05 UTC, TommiT wrote:
> On Friday, 1 February 2013 at 00:59:47 UTC, Zach the Mystic wrote:
>> writeln(foo.n); // uses alias this to call __mightAsWellBeOpGet
>
> No it won't. It will print "n()".
>
> And that exactly (passing to a templated parameter) is the insurmountable problem in using a variable to represent a property.

to!string(foo.n)... hmmm... not that I know how to solve it right away, but is it possible to do:

alias template theFuncIActuallyWant this;

int theFuncIActuallyWant() { return 1; }

...in order to have it pass the right thing to the template parameter? That's just a jury rigged syntax which might help structs make more sense to the compiler when passed through templates. You say it's insurmountable, and I don't know enough about the details to know, but it seems like surely SOMETHING could be done to get the right result without messing up everything else in the process.

On Thursday, January 31, 2013 18:58:00 Steven Schveighoffer wrote:
> I'm pretty sure structs are forbidden to have internal pointers.  They must be able to be moved without any post-processing.

Structs must be moveable. I believe that you can technically have a struct with a pointer refering to one of its members, but if you do, it will break as soon as your struct is moved (which _will_ happen).

- Jonathan M Davis

On Friday, 1 February 2013 at 02:52:42 UTC, Zach the Mystic wrote:
> I need to study this principle a little more. In other words, alias this is a templated parameter in this case? Which page is the documentation for these templated parameters, because I didn't see templates in my code.

No, alias this is basically implicit cast operator that will be tried if everything else fails. But writeln is a function template, i.e. its parameters/arguments are templated.

http://dlang.org/template.html

On Friday, 1 February 2013 at 02:27:30 UTC, TommiT wrote:
> And here's another example of why it is as big of a problem as I make it sound to be:
>
> import std.concurrency;
>
> struct Array
> {
>     int _len;
>
>     length struct // Using Zach's syntax
>     {
>         @property get() { return _len; }
>         alias this = get;
>         void opAssign(int rhs) { _len = rhs; }
>     }
> }
>
> void func(T)(T t)
> {
>     auto v = t;
>     v = 10;
> }
>
> void main()
> {
>     Array arr;
>     spawn(&func!int, arr.length);
>     arr.length = 20; // And here we have a data-race.
>                      // Good luck trying to find these
>                      // kinds of bugs.
> }

I'm sorry, I know very little about race conditions. If you might explain just a little bit about what is happening here, I'd be in a better position to understand what you're saying. I really can't say anything other than please describe what this does and why it's a problem at this time.

On Friday, February 01, 2013 01:01:02 Jesse Phillips wrote:
> I think his suggestions need implemented regardless of what we do with @property. I think Walter just felt this would appease the pro-property.

Well, it doesn't even come close. For the most part, the pro-@property folks want explicit proprties, and that's precisely what Walter is proposing that we get rid of.

> writeln = "hi" would not compile with Walters suggested changes.

Only because it's variadic. Something like

range.popFrontN = 7;

_would_ compile. And that's just as bad. We need explicit setter properties in order to avoid letting assignment work with functions where it makes no sense for it to work.

- Jonathan M Davis

On Friday, 1 February 2013 at 03:08:12 UTC, Zach the Mystic wrote:
> On Friday, 1 February 2013 at 01:53:05 UTC, TommiT wrote:
>> On Friday, 1 February 2013 at 00:59:47 UTC, Zach the Mystic wrote:
>>> writeln(foo.n); // uses alias this to call __mightAsWellBeOpGet
>>
>> No it won't. It will print "n()".
>>
>> And that exactly (passing to a templated parameter) is the insurmountable problem in using a variable to represent a property.
>
> to!string(foo.n)... hmmm...

I think this is taken care of actually, with opCast(string). The docs for std.conv.to with opCast may contain a typo:

"toImpl(T, S)(S value);
When source type supports member template function opCast, is is used."

I think it might mean "it is used" since I don't know why it would use "is" instead of the opCast. If that's true, just override opCast(string), no?

Still, it would be great to be able to "prefer" a particular alias this when passed to templates.

On Friday, 1 February 2013 at 03:08:12 UTC, Zach the Mystic wrote:
> alias template theFuncIActuallyWant this;
>
> int theFuncIActuallyWant() { return 1; }
>
> ...in order to have it pass the right thing to the template parameter? That's just a jury rigged syntax which might help structs make more sense to the compiler when passed through templates.

None of the alias this conversions are even looked at when you pass a variable to a templated parameter. The template simply conforms to whatever type the passed variable is. No conversions ever happen. That's just how templates work in D. I can't right off the bat say that it's impossible to design a language where templates perform conversions. But it's safe to say that it's not happening with this language. It would be a huge change.

On Friday, 1 February 2013 at 03:12:29 UTC, TommiT wrote:
> On Friday, 1 February 2013 at 02:52:42 UTC, Zach the Mystic wrote:
>> I need to study this principle a little more. In other words, alias this is a templated parameter in this case? Which page is the documentation for these templated parameters, because I didn't see templates in my code.
>
> No, alias this is basically implicit cast operator that will be tried if everything else fails. But writeln is a function template, i.e. its parameters/arguments are templated.
>
> http://dlang.org/template.html

If what you say is true, then all the more reason to build opGet into the compiler...

Was I correct in saying that the template in question was to!string(foo.n)? Or does the problem occur in passing to writeln() itself?

On Friday, 1 February 2013 at 03:28:05 UTC, TommiT wrote:
> On Friday, 1 February 2013 at 03:08:12 UTC, Zach the Mystic wrote:
>> alias template theFuncIActuallyWant this;
>>
>> int theFuncIActuallyWant() { return 1; }
>>
>> ...in order to have it pass the right thing to the template parameter? That's just a jury rigged syntax which might help structs make more sense to the compiler when passed through templates.
>
> None of the alias this conversions are even looked at when you pass a variable to a templated parameter. The template simply conforms to whatever type the passed variable is. No conversions ever happen. That's just how templates work in D. I can't right off the bat say that it's impossible to design a language where templates perform conversions. But it's safe to say that it's not happening with this language. It would be a huge change.

What I meant to suggest was an actual new feature which would allow one preferred argument to be passed to a template.