On Wednesday, 23 January 2013 at 19:18:09 UTC, Johannes Pfau wrote:
> int DG() {return 42};
> int delegate() getDG() {return &DG};
>
> auto dg = getDG; //OK
> auto ??? = getDG();
>
> The last line could be a call to getDG with optional parenthesis,
> so ??? = DG. Or it could be a call to getDG without optional
> parenthesis and a call to the returned DG, so ??? = 42.

If getDG is a @property, ??? == 42, because getDG() is rewritten into (getDG())() - parens there would ALWAYS mean "call the return value", so any @property is indistinguishable from its return value. (if we get @property like I want)

Without @property, it'd return DG because while parenthesis are optional, if they are present, they always apply to the preceding thing directly; getDG == getDG() in all cases. (This is the status quo, which I'd retain)


The type system will help catch errors here better than the syntax.

On Wednesday, 23 January 2013 at 19:29:44 UTC, Nick Sabalausky wrote:
> int foo() {...}
> int delegate() {...} bar;
>
> auto x = foo; // call it
> auto y = bar; // don't call it

I don't have a problem with that because delegates and functions are different beasts anyway. For one major example, you can't rebind a function, but you can rebind a delegate, so "bar" has a meaning that "foo" doesn't (and &bar and &foo are different beasts too, one is address of a (rebindable) pointer, the other is address of a function, so they won't match up either).

On 1/23/13 1:18 PM, Johannes Pfau wrote:
> Please do not forget the main reason for @property: Returning a
> delegate from a function can become ambiguous without it:
>
> int a(){return 42;}
> void b() {return&a;}
>
> auto var = b; //OK
> auto var2 = b(); //is var2 == b or == 42?
>
> It might be an extreme corner case, but it's inconsistent behavior and
> confusing.

Agreed. I think we should require @property only for those cases, and not any others.

Andrei

On 1/23/13 1:48 PM, Nick Sabalausky wrote:
> Having the *caller* decide whether something is a property or not makes
> as much sense as having the caller decide the function's name,
> signature and semantics.

No. The caller does get to decide a variety of syntactic aspects of the invocation.

> If anything, that's an issue with template syntax, it has nothing to do
> with properties, let alone the beloved practice of abusing properties
> for the sake of things that clearly are not properties.

The implied assumption here is that if it doesn't have parens it's a property. Well it's a function call.


Andrei

On Wednesday, 23 January 2013 at 18:02:05 UTC, Jonathan M Davis wrote:
> On Wednesday, January 23, 2013 18:03:19 monarch_dodra wrote:
>> So I thought I'd discuss: Would there be a reason to not make dur
>> a property? This should impact no-one, but make ufcs usage that
>> much more convenient. Can I get the go-ahead to make and document
>> the change?
>
> No. It's not conceptually a property, so it shouldn't be marked with
> @property. It's a factory function.
>

I agree. It's important we don't conflate properties with parentheses-less calling.  They are two separate things.

I want to be able to call without parentheses but we shouldn't abuse @property to accomplish it.

BA

On 1/23/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Wednesday, 23 January 2013 at 17:13:05 UTC, Timon Gehr wrote: Amen! -property MUST die. @property should fix the real problems with properties, not leave that broken while adding new problems.

About @property problems, I've recently ran into this: ModuleInfo.unitTest is defined as

@property void function() unitTest() nothrow pure;

And if I use it:

    foreach (m; ModuleInfo)
    {
        if (m is null)
            continue;

        if (auto fp = m.unitTest)
        {
            fp();           // calls it
            m.unitTest();   // doesn't call it
            m.unitTest()(); // calls it
        }
    }

This is regardless of the -property switch. I would expect the second call to work. Anyone know if this is filed already?

On 2013-01-23 18:03, monarch_dodra wrote:
> I was using dur, and as powerful as it is, I *hate* typing:
>
> //----
> Thread.sleep(dur!"msecs"(100));
> //----
>
> Then, this reminded me of an older thread I started:
> Neat: UFCS for integer dot operator suffix
> http://forum.dlang.org/thread/uchcycnsvykuojzhuokh@forum.dlang.org
>
> And then it struct me:
> //----
> Thread.sleep(100.dur!"msecs");
> //----
>
> Yay! Or even better:
> //----
> alias msecs = dur!"msecs"
> ...
> Thread.sleep(100.msecs); //Wow. Talk about expressive !!!

This is how it should look like. Date ranges in Ruby on Rails can be really beautiful:

date = 2.days.ago

I think we should have the same in D.

> What about making things like msecs public aliases? How do you feel
> about that?

Go for it.

-- 
/Jacob Carlborg

On 2013-01-23 19:08, Adam D. Ruppe wrote:

> My preferred solution is:
>
> 1) all functions without @property work exactly the same way they do now
> (optional parenthesis, callable as setters with =)
>
> 2) all functions with @property are ALWAYS rewritten so that a reference
> to them instead references the return value and/or the setter function.
>
> So the result would be similar to #define t.foo (t.foo()). The type
> system then takes care of the parenthesis - no special code is required
> for syntax.

What about functions not marked with @property?

writeln = "asd";

Doesn't look very nice.

-- 
/Jacob Carlborg

On 2013-01-23 19:18, Johannes Pfau wrote:

> It might be an extreme corner case, but it's inconsistent behavior and
> confusing. Need a real-world example?
> http://www.digitalmars.com/d/archives/digitalmars/D/ModuleInfo.unitTest_cannot_be_called_twice_183357.html
> (with proper @property the first example should work as expected).

Yeah, that was kind of embarrassing.

-- 
/Jacob Carlborg

On 2013-01-23 19:48, Nick Sabalausky wrote:

> Having the *caller* decide whether something is a property or not makes
> as much sense as having the caller decide the function's name,
> signature and semantics.

In Ruby parentheses are optional when calling a method. I have never had any problem with that, although in Ruby you invoke a callable object with ".call". Property setters are more explicit in Ruby than D:

def foo= (value)
end

The equal sign is actually part of the method name.

-- 
/Jacob Carlborg