January 23, 2013
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.
January 23, 2013
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).
January 23, 2013
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
January 23, 2013
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

January 23, 2013
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
January 23, 2013
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?
January 23, 2013
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
January 23, 2013
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
January 23, 2013
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
January 23, 2013
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
1 2 3 4 5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home