November 20, 2012
On Tuesday, 20 November 2012 at 05:31:09 UTC, deadalnix wrote:
> This make it impossible to only define a getter only when one want to return by reference.

If there isn't a setter, you don't change things.

If setter is present:
foo = foo + 1; // becomes: foo(foo() + 1);

If setter is not present:
foo = foo + 1; // becomes: foo() = foo() + 1;


If foo returns an rvalue, this is a natural error. If it returns ref, it works fine.
November 20, 2012
On Tue, 20 Nov 2012 13:26:15 -0000, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>> Should this be allowed for functions that isn't marked with @property:
>>
>> foo = 3;
>
> Yes. We should *only* be changing the way @property is implemented. (Namely, actually implementing it!)
>
> Don't want to break existing code. The new changes must be opt in.

Usually I'd agree but this is a case of a wart we should just remove IMO.  The fix for breaking cases is simple, add @property.

> If there's both an @property setter and a regular function, the property should be used here.

Agreed.  But it's waay clearer whats going on if @property is required to call functions using this syntax.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 20, 2012
On Tue, 20 Nov 2012 13:20:10 -0000, monarch_dodra <monarchdodra@gmail.com> wrote:

> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>> Should this be allowed for functions that isn't marked with @property:
>>
>> foo = 3;
>
> Hell no!

+1 I think this "feature" should just be removed, and @property implemented fully/correctly.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 20, 2012
On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
> Usually I'd agree but this is a case of a wart we should just remove IMO.  The fix for breaking cases is simple, add @property.

meh, I sometimes use it, but if overloading on @property works, that's easy enough to allow both ways.

I use it in some big chaining things:

Element.make("div").className("foo").value = "bar";

vs

auto element = Element.make("div");
element.className = "foo";
element.value = "bar";


Using one or the other depending on if I have a variable name there anyway. This would be arguably *better* with separation, but I don't have the level of hatred for one function used both ways (on setter nor getter) the way a lot of people do.
November 20, 2012
BTW I've been pasting some of my posts into the wiki thing

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21#section4


Kinda sloppy to just paste, but this way everything on my mind is in one place so we don't have to reread the thread to get it together.

Of course, being a wiki, feel free to do the same with anything you want to note.
November 20, 2012
On Tuesday, 20 November 2012 at 14:13:51 UTC, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
>> Usually I'd agree but this is a case of a wart we should just remove IMO.  The fix for breaking cases is simple, add @property.
>
> meh, I sometimes use it, but if overloading on @property works, that's easy enough to allow both ways.
>
> I use it in some big chaining things:
>
> Element.make("div").className("foo").value = "bar";
>
> vs
>
> auto element = Element.make("div");
> element.className = "foo";
> element.value = "bar";

That's a good point. If the property is a "setter", then both "value = bla" and "value(bla)" is legal.

If the property is a getter, then only "=" works. But I think it would be fine if "value(bla)" were tanslated to "value = bla" in that case.

However, if you allow "foo = rhs" => "foo(rhs)" on a non-propety, then code like this becomes legal:
writeln = 5;
And that's bullshit.
November 20, 2012
On Tuesday, 20 November 2012 at 13:26:17 UTC, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>> Should this be allowed for functions that isn't marked with @property:
>>
>> foo = 3;
>
> Yes. We should *only* be changing the way @property is implemented. (Namely, actually implementing it!)
>
> Don't want to break existing code. The new changes must be opt in.

Here's another way to test if the idea is sound, by asking a few questions:

For some time, we've had the unrestricted ability to drop empty "()" and perform assignments to any function with appropriate sig. Has there been a chorus of complaints about having it? Any flood of problems caused by it? More importantly, how many of us are now making good use out of it without even a seconds thought? How many of us would really miss it if taken out?

I still think there's a lot more to the picture, but I cannot yet pin it down well enough to say what it is.

I'll try and share my thoughts, so that maybe someone more knowledgeable than me can figure it out.

What is really bugging me, is that I know there's something more generalized going on here that we may have an opportunity to take advantage of, before things get cast in "unbreakable" stone, so to speak.

I've been asking myself some questions, off the wall stuff, not necessarily possible for D due to practical limitations, but perhaps possible for E:

1) Why must a variable operate as it does and why must a function operate as it does? Are the two "things" really all that much different? I can successfully imagine that a variable is a function wrapper around a data store.

2) We're allowing only some functions to operate like variables, and this is because not all functions are allowed to operate in this way due to their parameter signature. Specifically, if the function has more than one parameter, it cannot be used as if it were a variable.

Example:

// We can do this

void Foo( int ){ ... };
int Foo(){ ... };
Foo = 5;
int Y = Foo;

// so why not something like this?

void Foo( int, string, float ){ ... };
( int, string, float )Foo(){ ... };

Foo = { 1, "test", 3.456 };
{ someint, somestring, sonefloat } = Foo;

Why must we be limited to a single return and a single assignment value?
(I recall this topic was brought up before, and I know we can use struct to emulate a similar effect)

3) If some functions can operate like variables, then why must no variable be able to operate like some functions?

This is not allowed in D:

int x, y;
x(1);
y = x();
y(x());

Why must this be so?

4) Which syntax or constructs are easier to understand, and which are not, given the context they are used in? If we had choice, will the context prefer one syntax over another in terms of clarity? If we don't have choice, then the context may enforce poor clarity in some cases.

5) We really enjoy the power we get from generic templates, yet the generic abilities of templates may possibly be lessened considerably because of the incompatibility between variables and functions, and I would also say classes and structs, although with UFCS the situation has improved (which may be why we like having them so much).

6) What advantage do we get by making variables and functions incompatible with each other (in terms with how they are manipulated or operated on), and what advantages could we get if we made them fully compatible (or at least more compatible).

Hopefully some of these questions will provide food for some thought on the @property matter.

--rt

November 20, 2012
Just a quick thought... it's not like a = 10 has no way to trigger a function anyway.

opAssign does it. Is that evil? This discussion kinda reminds me of some of the C++ arguments over operator overloading. They argue overloaded operators are evil because they don't look like function calls... but I think most of us agree that is generally useful.

D's properties of course aren't exactly the same but I think there's some similarities there that matter.
November 20, 2012
On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote:
> Here's another way to test if the idea is sound, by asking a few questions:

After thinking about it a bit more, I think there may be two conflicting notions:

a) The use of optional parenthesis.
b) The @property switch, which allows a function to emulate an attribute, namelly, allow writting "bla = a.foo;" or "a.foo = 5;", when "foo" isn't actually an attribute of a.

I *could* see parenthesis being optional, but I'll never accept "a.foo = 5" calling "a.foo(5)" if "foo" isn't attribute qualified.
November 20, 2012
On Tuesday, November 20, 2012 19:48:01 monarch_dodra wrote:
> On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote:
> > Here's another way to test if the idea is sound, by asking a
> 
> > few questions:
> After thinking about it a bit more, I think there may be two conflicting notions:
> 
> a) The use of optional parenthesis.
> b) The @property switch, which allows a function to emulate an
> attribute, namelly, allow writting "bla = a.foo;" or "a.foo =
> 5;", when "foo" isn't actually an attribute of a.

Yes, you basically have folks who want to have strictly defined properties which emulate variables (similar to what C# has), and you have folks who simply want to leave off parens (especially when they're using UFCS and already forced to provide a template argument - e.g. with map or filter or whatnot). On some level, they can coexist, and on some level, they're conflicting notions.

Given the fact that this subject is extremely devisive, I suspect that the best that we can hope for at this point is for lax property enforcement - that is that it's enforced that @property functions are used as properties but there is no enforcement that non-@property functions be called with parens. We might be able to further restrict them so that they can't be used with the setter syntax (making it so that they must be @property for that to work), but with UFCS and the use of templated functions taking predicates, dropping parens is way too popular to disallow it, much as I personally hate the idea.

- Jonathan M Davis