On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
> To me the whole property discussion looks like one of those endless debates about an insignificant detail.
> Scala and Ruby seem to do well with sloppy parens.

Strict typing and explicitness has a real effect on code legibility and maintenance. D is trying too hard to be a scripting language. Taking away getter/setter typing just reinforce that impression.

> With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front.

Introduce a pipeline operator. Chaining processes with dot operators has always been an ugly old OO hack.

> For some functions it's really hard to decide whether or not something is a property, e.g. for me Range.save is an action/function not a property. So for me using @property appears to waste time making pointless decisions.

If it is hard to decide then that probably means that the model is flawed and needs more work.

D really needs to start strengthening the type system, rather than eroding it.

On 2015-10-10 03:52, Martin Nowak wrote:

> Scala and Ruby seem to do well with sloppy parens.

A few notes about why Ruby doesn't have the same problems as D has:

1. Ruby has optional parentheses for all method calls, regardless if they accept arguments or not

2. Ruby has a different syntax for calling lambdas from calling functions:

def foo
end

foo() # calling function

a = -> { }
a.call # calling lambda
a.() # alternative syntax for calling lambda

In Ruby, no one will ever use empty parentheses for calling a method.

3. You can not use the setter syntax for a "regular" method taking one argument:

class Foo
  def bar(a)
  end

  def foo=(a) # not the same name as "foo"
  end
end

a = Foo.new
a.bar = 3 # error
a.foo = 3 # ok
a.foo(3) # error

-- 
/Jacob Carlborg

On 10 October 2015 at 14:51, Jacob Carlborg via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On 2015-10-10 03:52, Martin Nowak wrote:
>
> Scala and Ruby seem to do well with sloppy parens.
>>
>
> A few notes about why Ruby doesn't have the same problems as D has:
>
> 1. Ruby has optional parentheses for all method calls, regardless if they accept arguments or not
>
> 2. Ruby has a different syntax for calling lambdas from calling functions:
>
> def foo
> end
>
> foo() # calling function
>
> a = -> { }
> a.call # calling lambda
> a.() # alternative syntax for calling lambda
>
> In Ruby, no one will ever use empty parentheses for calling a method.
>
> 3. You can not use the setter syntax for a "regular" method taking one argument:
>
> class Foo
>   def bar(a)
>   end
>
>   def foo=(a) # not the same name as "foo"
>   end
> end
>
> a = Foo.new
> a.bar = 3 # error
> a.foo = 3 # ok
> a.foo(3) # error
>
>
It seems to be a misfeature of D to accept the equivalent of all three of those examples as valid.

On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg wrote:
> In Ruby, no one will ever use empty parentheses for calling a method.

That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.

On Saturday, October 10, 2015 02:57:01 Meta via Digitalmars-d-announce wrote:
> On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
> > That's what I meant, weird use-case, at best it's a callback
> > better/setter.
> > I've never written such code, but even if you would, the 2
> > pairs of parens are only a tiny problem for generic code,
> > nothing to warrant the invasive language feature @property is.
>
> I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens.

Optional parens definitely do not help with generic code - quite the opposite. In generic code, it needs to be clear whether a symbol is supposed to represent a field or a function. If it's a field, you call it without parens. If it's a function, it has to be called with parens if it's supposed to be possible to have the symbol emulate a function rather than be a function (e.g. be a delegate).

We mostly get away with optional parens on function calls in generic code, because it's pretty rare that we write code that's expecting a function and is given a delegate, except in the cases (like predicates) where we clearly expect any kind of callable, and we have to use template wrappers (e.g. std.functional.binary) in those cases in order to make them all act the same and not care about what exactly we're getting.

For symbols that are supposed to act like fields, they can't be called with parens in generic code, or they won't work generically, and unlike with symbols that are supposed to act like functions, it's _very_ common to get a mix of variables and functions for the same symbol across different types. So, generic code that uses parens on what is supposed to be a field will work with a function but fail miserably if the type it's given implemented that symbol as a variable. And that's common enough that generic code needs to get it right, whereas it can mostly get away with it with symbols that represent functions simply due to the fact that they're pretty much always implemented as functions.

I don't think that there's any question that generic code would be better off if we didn't have optional parens and if functions which used the property syntax weren't allowed to be called with parens. And D programs typically have a lot of generic code.

The problem is that when folks are writing code that uses generic functions (rather than necessarily being inside of generic functions), they like to leave off the parens and think that it's ugly to be required to have them. So, we don't have full property enforcement and will never get it. But that same laxity inside of generic code easily leads to compilation failures when properties are used simply because a function will work with parens (be it an @property function or not) whereas variables won't.

Hands down, I think that we'd be better off with strict property enhancement due to all of the generic code that we deal with, but that water is long since under the brigde.

Instead, we're forever going to be forced to be even more thorough with unit testing in order to make sure that templated functions don't use parens on symbols that are supposed to be properties/fields and to make sure that it does use parens on something that is supposed to be a function. Since, any time we don't do that, we risk making mistakes and writing generic code that doesn't work with all of the types that it's supposed to work with.

The only question at this point is whether we can at least get partial property enforcement out of @property and reduce the number of bugs in generic code or whether @property is pretty much just going to be tossed out.

- Jonathan M Davis

On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
> Right, ideally a @proptery function can perfectly replace a variable, but practically calling the return value seems far fetched.
> What would you use that for, a handwritten interface struct with function pointers made read-only using @property?
>

It doesn't matter. If you want an explosion of special cases, there is already a language for that, it is called C++.

Every time an exception is introduced, the "burden of proof" is to prove this exception actually bring sufficient value to pay for itself, not the other way around.

> To me the whole property discussion looks like one of those endless debates about an insignificant detail.
> Scala and Ruby seem to do well with sloppy parens.

For what I've touched of ruby, the language is very permissive and nice. This is good when you do your first prototype, but this is also what causes it to be intractable at scale (and also impossible to optimize, but that is beside the point here).

Is the parentheses thing a problem ? Not really on its own, but it compound.

The parentheses thing and with it the special _ syntax to NOT call a function is not considered as a good thing by most scala people I've talked to.

> With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front.
> For some functions it's really hard to decide whether or not something is a property, e.g. for me Range.save is an action/function not a property. So for me using @property appears to waste time making pointless decisions.

One can reach the desired effect by having a consistent set of rules and define the calling as a fallback rewrite when there is an error. Namely, add a rule that says : if this is an error, add () and retry. Here you go, problem solved, you can use parentheses function call in every places it is not ambiguous without introducing Byzantines set of rules into the language.

On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg wrote:
>> In Ruby, no one will ever use empty parentheses for calling a method.
>
> That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.

That's actually quite beautiful in its simplicity.

On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
> On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
>> That's what I meant, weird use-case, at best it's a callback better/setter.
>> I've never written such code, but even if you would, the 2 pairs of parens are only a tiny problem for generic code, nothing to warrant the invasive language feature @property is.
>
> I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens.
>
> Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.

To the next person that is going to say this is overblown, I ran into such bugs more than once in phobos.

So, unless we expect most D developer to be better than phobos contributor, that is a problem.

On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
> First beta for the 2.069.0 release.
>
> http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html
>
> Please report any bugs at https://issues.dlang.org
>
> -Martin

First beta, so far I can use it as a drop in replacement. Nothing broke. It's like magic :)

Very good job :)

Am Sun, 11 Oct 2015 01:54:39 +0000
schrieb deadalnix <deadalnix@gmail.com>:

> On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
> > On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
> >> That's what I meant, weird use-case, at best it's a callback
> >> better/setter.
> >> I've never written such code, but even if you would, the 2
> >> pairs of parens are only a tiny problem for generic code,
> >> nothing to warrant the invasive language feature @property is.
> >
> > I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens.
> >
> > Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.
> 
> To the next person that is going to say this is overblown, I ran into such bugs more than once in phobos.
> 
> So, unless we expect most D developer to be better than phobos contributor, that is a problem.
> 

We even have such a problem in object.d:

https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461

I remember somebody asking in D.learn why his custom test runner did
not work. Problem was related to wrong parenthesis: The user wrote
mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't
find the exact link right now.