Do we want functions to act as properties, or merely omit parens for ufcs/chaining?

[Chad Joan]

On 01/29/2013 06:03 AM, sclytrack wrote:
> On Tuesday, 29 January 2013 at 10:34:59 UTC, Sönke Ludwig wrote:
>> Am 29.01.2013 05:16, schrieb sclytrack:
>>> On Tuesday, 29 January 2013 at 01:09:17 UTC, F i L wrote:
>>>> why in the hell would you want:
>>>>
>>>> writeln = "lolwut";
>>>>
>>>> to compile in the first place?
>>>
>>> If you disallow this. You will have to invent something else than
>>> opDispatch.
>>> Something that serves them both. opPropMethodDispatch maybe.
>>
>>
>> template opDispatch(string name)
>> {
>> static if( isAProperty!name ){
>> @property int opDispatch() { return 0; }
>> } else {
>> void opDispatch() {}
>> }
>> }
>>
>> or similar should work.
>
> I meant for dynamic D where you don't know if it is a property or a
> method at compile time. Where you don't know if the method even exists
> or not.
>
> Overloading on an annotation is just weird. Either something is
> annotated or not.
>
> Going to eat now.
>
>

I didn't think it was an overload.  I also don't understand the bit 
about dynamic D, because the dispatch in opDispatch always occurs at 
compile-time.  Any strings used as method names on a type with 
opDispatch must be known at compile-time.  This is reasonably expressive 
enough that I wonder if you're doing other dynamic calculations behind 
that all.

That template works, though I was also thinking about this natural use-case:

import std.stdio;

class Foo
{
	void opDispatch(string name)(int arg)
	{
		writefln("%s(%s) called",name,arg);
	}

	@property opDispatch(string name : "prop")(int arg)
	{
		writefln("prop = %s", arg);
	}
}

void main()
{
	auto f = new Foo();
	f.test(5);
	f.prop = 9;
}

// Writes:
// test(5) called
// prop = 9

This might be confusing to me because I'm not sure what your use case 
is.  How are you generating your opDispatch functions currently where 
this becomes a problem?