www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - ufcs and integer params

reply "Jay Norwood" <jayn prismnet.com> writes:
I was looking at the xtend example 4 Distances  here, and see 
that their new generation capability includes ability to do 3.cm 
10.mm , and these result in calls to cm(3) and mm(10).

  http://blog.efftinge.de/



I see that similar capability was discussed for D previously at 
the link below.  How was this issue resolved for D?

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=97661
Jul 14 2012
next sibling parent reply "Jay Norwood" <jayn prismnet.com> writes:
I see from this other discussions that it looks like 2.059 ( or 
maybe 2.060) does support something like 3.cm().   Not sure from 
the discussion if it would also accept 3.cm as in the xtext/xtend 
example.

http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org
Jul 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 05:40 AM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.

 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org

UFCS (universal function call syntax) was added in 2.059. If cm is a function, then 3.cm() will work. If it's a property function, then 3.cm will work. If you don't compile with -property, then 3.cm will still work with cm being a non-property function, but -property will become the normal behavior eventually, so you shouldn't expect that 3.cm will work long term unless cm is a property function.

I expect it to stay. Another reason why property-'enforcement' is flawed: property auto cm(int arg){ .. } cm=2; // ok 2.cm; // ok The two code snippets would in fact be equivalent. What is enforced here? Why would it matter if anything is 'enforced'?
Jul 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 09:41 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:
 What is enforced here? Why would it matter if anything is 'enforced'?

If you marked it as a property, then it's supposed to be abstracting a variable and should be treated as one, just like if it's a normal function, it should be invoked as a function, just like ++ shouldn't suddenly do --, and / shouldn't *.

And on a purely objective note, if you don't have property enforcement, you can't turn a property function into a variable, because even though it's supposed to be used as one, you can't guarantee that everyone's using it that way, and if they're using it as a function, changing the property into a variable will break their code. And part of the point of properties is to be able to switch between variables and property functions depending on whether additional protections or calculations or whatnot are required for that variable/property. Property enforcement is required in order to allow that. - Jonathan M Davis

No it is not, assuming that property enforcement is supposed to mean that function 'foo' cannot be called like 'foo' if it is not annotated property. There is no objective argument for banning this, except that the syntax would be made free for alternative use. property means: always implicitly call if it can be called without arguments. If it cannot, disallow calls that are not of the form fun = argument; (After the op= operators have been properly rewritten.) And that is completely sufficient for transparently switching between variable/property. Stuff that is *not* annotated property has no relevance.
Jul 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:11 PM, Jonathan M Davis wrote:
 There are two levels to enforcement. Neither exist without -property. The
 absolutely minimal level is that anything marked with  property must be used
 as a property.  Without this, you can't swap out a property function for a
 variable without breaking code.

If it means what I think it means then that should be done and this is where -property fails.
 The second level - i.e. strict property enforcement - also requires that non-
 property functions be called as functions.

Exactly. This part is useless. (The 'Without this, you can't...' part is notably missing.)
Jul 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.

Exactly. This part is useless.

And there, we will forever disagree.

If it is a matter of personal preference, then it shouldn't be in the compiler.
Jul 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:56 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:
 On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.

Exactly. This part is useless.

And there, we will forever disagree.

If it is a matter of personal preference, then it shouldn't be in the compiler.

It's a matter of enforcing the correct syntax,

This post seems to attempt to distract from the fact that the topic of the discussion is which syntax is correct.
 which the compiler does all the
 time. It's just that you don't think that the compiler should care in this
 particular case, since it hasn't cared in the past.

The compiler does not and has never 'not cared'. It has to do slightly more work. This is a designed language feature, although it's a trivial one. eg. Eiffel and Scala have the same thing. The prime reason why I think it is beneficial if no more restrictions than necessary are applied is UFCS: array(map!(x=>2*x)(range)); // should be fine range.map!(x=>2*x).array; // so should this range.map!(x=>2*x)().array(); // who needs this?
Jul 15 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-16 00:33, Timon Gehr wrote:

 This post seems to attempt to distract from the fact that the topic of
 the discussion is which syntax is correct.

 which the compiler does all the
 time. It's just that you don't think that the compiler should care in
 this
 particular case, since it hasn't cared in the past.

The compiler does not and has never 'not cared'. It has to do slightly more work. This is a designed language feature, although it's a trivial one. eg. Eiffel and Scala have the same thing. The prime reason why I think it is beneficial if no more restrictions than necessary are applied is UFCS: array(map!(x=>2*x)(range)); // should be fine range.map!(x=>2*x).array; // so should this range.map!(x=>2*x)().array(); // who needs this?

Exactly. -- /Jacob Carlborg
Jul 15 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/16/2012 10:55 AM, Chris NS wrote:
 Having been around long enough to remember when the ability to call
 "foo()" as "foo" first appeared, I feel it necessary to point out that
 this was *not* in fact a deliberate design, but rather a sort of
 "accident" that arose out of D's first attempt at properties.

Afaik this first attempt was implemented roughly as designed. It is my understanding that property was added later in order to fix the introduced ambiguities.
 It was the same "accident" loaded compiler release that gave us pseudo-members
--
 the precursors to UFCS.

I still wonder how that could possibly happen.
 The community discovered that these things were accepted by the compiler
 -- which was actually against the language spec at the time -- and
 further that the resulting code did the intuitively correct thing.
 Response to the "accidents" being generally positive, it was decided to
 work toward making them legitimate language features. Some flavor of
  property (or of a certain other proposal which was a mimicry of C#
 properties... I was in that camp)

That would certainly be more pretty -- OTOH it is hard to think of a way to extend this to UFCS that is as natural as what happens if everything is conflated in functions.
 has been in the plan ever since.

 I find the ongoing debate/discussion of  property and -property to be...
 well, moot. But hey, I'm just one crazy among an army of crazies.

Well, this newsgroup has the property that the stuff that is actually important is usually unilaterally agreed upon rather quickly. :o)
Jul 16 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-15 23:56, Jonathan M Davis wrote:

 It's a matter of enforcing the correct syntax, which the compiler does all the
 time. It's just that you don't think that the compiler should care in this
 particular case, since it hasn't cared in the past.

No, it's a matter of _what_ the correct syntax is. Just as both of these are legal: if (true) writeln(true); if (true) { writeln(true); } Both of these could be legal as well: void foo (); foo(); foo; There are several other languages where the parentheses are optional: Ruby, Scala and CoffeeScript to mention a few. -- /Jacob Carlborg
Jul 15 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 08:56 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 19:50:18 Timon Gehr wrote:
 On 07/15/2012 05:40 AM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.

 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org

UFCS (universal function call syntax) was added in 2.059. If cm is a function, then 3.cm() will work. If it's a property function, then 3.cm will work. If you don't compile with -property, then 3.cm will still work with cm being a non-property function, but -property will become the normal behavior eventually, so you shouldn't expect that 3.cm will work long term unless cm is a property function.

I expect it to stay. Another reason why property-'enforcement' is flawed: property auto cm(int arg){ .. } cm=2; // ok 2.cm; // ok The two code snippets would in fact be equivalent.

property isn't perfect, and I admit that the fact that both cm = 2 and 2.cm works here is undesirable, given what's trying to be done here, but it makes sense given that it's abstracting a variable. It's just undesirable that you can't make it so that it functions only as a getter.

cm=2 is in fact a getter call. I don't mind this, because I don't need to write that code if I don't want to. The 'puritanical' view is simply incompatible with how the whole thing is laid out.
 But the overall situation
 is still a whale of a lot better than the laxity of letting just any function
 be called with or without parens depending no what each particular programmer
 feels like doing with it. If it's a property, it should be treated as such,
 and if it isn't, it shouldn't.

 What is enforced here? Why would it matter if anything is 'enforced'?

If you marked it as a property, then it's supposed to be abstracting a variable and should be treated as one, just like if it's a normal function, it should be invoked as a function,

This seems to be tautological. But what this statement presumably really meant to say was 'it should be invoked as a function using the notation present in eg. C or Java'.
 just like ++ shouldn't suddenly do --, and / shouldn't *.

That depends entirely on the domain of these functions.
 I don't want to get into this argument again.

Yah, we have gone through this before.
 The current plan is (and has been for some time)
 that -property will become the normal behavior,

It is obvious that -property is broken and will not become the normal behaviour.
Jul 15 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/15/2012 11:35 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:
 The current plan is (and has been for some time)
 that -property will become the normal behavior,

It is obvious that -property is broken and will not become the normal behaviour.

It is obvious that -property needs to be fixed before it becomes the normal behavior. It is _not_ obvious that it will not become the normal behavior. The -property flag was created explicitly so that its implementation could be fixed _before_ making it the normal behavior and so that programmers had time to fix their code before it become enforced. - Jonathan M Davis

I'd say the -property switch is there to make the fruitless bikeshedding discussions about property disappear. Nothing else makes sense. Its inclusion obviously has been rushed (the error message does not even follow English grammar) and it _only_ implements the one restriction that does not objectively matter.
Jul 15 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-15 21:41, Jonathan M Davis wrote:

 And on a purely objective note, if you don't have property enforcement, you
 can't turn a property function into a variable, because even though it's
 supposed to be used as one, you can't guarantee that everyone's using it that
 way, and if they're using it as a function, changing the property into a
 variable will break their code. And part of the point of properties is to be
 able to switch between variables and property functions depending on whether
 additional protections or calculations or whatnot are required for that
 variable/property. Property enforcement is required in order to allow that.

Due to various other reasons this is still not possible. * You cannot turn a virtual method into a variable * For some type of variables you cannot change the variable into a method. We would need some kind of property rewrite -- /Jacob Carlborg
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.
 
 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org

UFCS (universal function call syntax) was added in 2.059. If cm is a function, then 3.cm() will work. If it's a property function, then 3.cm will work. If you don't compile with -property, then 3.cm will still work with cm being a non-property function, but -property will become the normal behavior eventually, so you shouldn't expect that 3.cm will work long term unless cm is a property function. - Jonathan M Davis
Jul 14 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--f46d043bd6fae3319f04c4e17b90
Content-Type: text/plain; charset=UTF-8

 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.


Hi Jay, I had a little fun with coding a units (SI units) system in D and pushed an incomplete version on Github a few weeks ago: https://github.com/PhilippeSigaud/Units It allows things like: auto distance = 100.km; auto speed = 120.km/hour; auto timeToDestination = distance/speed; // timeToDest is a time (seconds) The version on Github is grossly limited (it's just a sketch), but it gives an idea of what's possible. My goal is to code a generic unit system generator, given user inputs such as a list of units and sub-units. cheers, Philippe --f46d043bd6fae3319f04c4e17b90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p><br> &gt; On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:<br> &gt; &gt; I see from this other discussions that it looks like 2.059 ( or<b= r> &gt; &gt; maybe 2.060) does support something like <a href=3D"http://3.cm">= 3.cm</a>(). =C2=A0 Not sure from<br> &gt; &gt; the discussion if it would also accept <a href=3D"http://3.cm">3.= cm</a> as in the xtext/xtend<br> &gt; &gt; example.</p> <p>Hi Jay,<br></p> <p>I had a little fun with coding a units (SI units) system in D and pushed= an incomplete version on Github a few weeks ago:</p> <p><a href=3D"https://github.com/PhilippeSigaud/Units">https://github.com/P= hilippeSigaud/Units</a></p> <p>It allows things like:</p> <p>auto distance =3D <a href=3D"http://100.km">100.km</a>;<br> auto speed =3D <a href=3D"http://120.km/hour">120.km/hour</a>;</p> <p>auto timeToDestination =3D distance/speed; // timeToDest is a time (seco= nds)</p> <p>The version on Github is grossly limited (it&#39;s just a sketch), but i= t gives an idea of what&#39;s possible. My goal is to code a generic unit s= ystem generator, given user inputs such as a list of units and sub-units.</= p> <p>cheers,</p> <p>Philippe<br> </p> --f46d043bd6fae3319f04c4e17b90--
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 19:50:18 Timon Gehr wrote:
 On 07/15/2012 05:40 AM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.
 
 http://forum.dlang.org/thread/smoniukqfxerutqrjshf forum.dlang.org

UFCS (universal function call syntax) was added in 2.059. If cm is a function, then 3.cm() will work. If it's a property function, then 3.cm will work. If you don't compile with -property, then 3.cm will still work with cm being a non-property function, but -property will become the normal behavior eventually, so you shouldn't expect that 3.cm will work long term unless cm is a property function.

I expect it to stay. Another reason why property-'enforcement' is flawed: property auto cm(int arg){ .. } cm=2; // ok 2.cm; // ok The two code snippets would in fact be equivalent.

property isn't perfect, and I admit that the fact that both cm = 2 and 2.cm works here is undesirable, given what's trying to be done here, but it makes sense given that it's abstracting a variable. It's just undesirable that you can't make it so that it functions only as a getter. But the overall situation is still a whale of a lot better than the laxity of letting just any function be called with or without parens depending no what each particular programmer feels like doing with it. If it's a property, it should be treated as such, and if it isn't, it shouldn't.
 What is enforced here? Why would it matter if anything is 'enforced'?

If you marked it as a property, then it's supposed to be abstracting a variable and should be treated as one, just like if it's a normal function, it should be invoked as a function, just like ++ shouldn't suddenly do --, and / shouldn't *. I don't want to get into this argument again. The current plan is (and has been for some time) that -property will become the normal behavior, and there have been no indications that that's going to change. I know that you don't like it, but some of us think that it's a major improvement, even if the result isn't perfect. The only way that it's going to change is if Walter changes his mind. - Jonathan M Davis
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:
 What is enforced here? Why would it matter if anything is 'enforced'?

If you marked it as a property, then it's supposed to be abstracting a variable and should be treated as one, just like if it's a normal function, it should be invoked as a function, just like ++ shouldn't suddenly do --, and / shouldn't *.

And on a purely objective note, if you don't have property enforcement, you can't turn a property function into a variable, because even though it's supposed to be used as one, you can't guarantee that everyone's using it that way, and if they're using it as a function, changing the property into a variable will break their code. And part of the point of properties is to be able to switch between variables and property functions depending on whether additional protections or calculations or whatnot are required for that variable/property. Property enforcement is required in order to allow that. - Jonathan M Davis
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 22:47:41 Timon Gehr wrote:
 On 07/15/2012 09:41 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 11:56:57 Jonathan M Davis wrote:
 What is enforced here? Why would it matter if anything is 'enforced'?

If you marked it as a property, then it's supposed to be abstracting a variable and should be treated as one, just like if it's a normal function, it should be invoked as a function, just like ++ shouldn't suddenly do --, and / shouldn't *.

And on a purely objective note, if you don't have property enforcement, you can't turn a property function into a variable, because even though it's supposed to be used as one, you can't guarantee that everyone's using it that way, and if they're using it as a function, changing the property into a variable will break their code. And part of the point of properties is to be able to switch between variables and property functions depending on whether additional protections or calculations or whatnot are required for that variable/property. Property enforcement is required in order to allow that. - Jonathan M Davis

No it is not, assuming that property enforcement is supposed to mean that function 'foo' cannot be called like 'foo' if it is not annotated property. There is no objective argument for banning this, except that the syntax would be made free for alternative use. property means: always implicitly call if it can be called without arguments. If it cannot, disallow calls that are not of the form fun = argument; (After the op= operators have been properly rewritten.) And that is completely sufficient for transparently switching between variable/property. Stuff that is *not* annotated property has no relevance.

There are two levels to enforcement. Neither exist without -property. The absolutely minimal level is that anything marked with property must be used as a property. Without this, you can't swap out a property function for a variable without breaking code. The second level - i.e. strict property enforcement - also requires that non- property functions be called as functions. -property is supposed to be doing strict property enforcement, but it's pretty buggy at the moment, so you can't really use it to guarantee much yet. - Jonathan m Davis
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:
 The current plan is (and has been for some time)
 that -property will become the normal behavior,

It is obvious that -property is broken and will not become the normal behaviour.

It is obvious that -property needs to be fixed before it becomes the normal behavior. It is _not_ obvious that it will not become the normal behavior. The -property flag was created explicitly so that its implementation could be fixed _before_ making it the normal behavior and so that programmers had time to fix their code before it become enforced. - Jonathan M Davis
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.

Exactly. This part is useless.

And there, we will forever disagree. - Jonathan M Davis
Jul 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:
 On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
 The second level - i.e. strict property enforcement - also requires that
 non- property functions be called as functions.

Exactly. This part is useless.

And there, we will forever disagree.

If it is a matter of personal preference, then it shouldn't be in the compiler.

It's a matter of enforcing the correct syntax, which the compiler does all the time. It's just that you don't think that the compiler should care in this particular case, since it hasn't cared in the past. - Jonathan M Davis
Jul 15 2012
prev sibling next sibling parent "Chris NS" <ibisbasenji gmail.com> writes:
Having been around long enough to remember when the ability to 
call "foo()" as "foo" first appeared, I feel it necessary to 
point out that this was *not* in fact a deliberate design, but 
rather a sort of "accident" that arose out of D's first attempt 
at properties.  It was the same "accident" loaded compiler 
release that gave us pseudo-members -- the precursors to UFCS.

The community discovered that these things were accepted by the 
compiler -- which was actually against the language spec at the 
time -- and further that the resulting code did the intuitively 
correct thing.  Response to the "accidents" being generally 
positive, it was decided to work toward making them legitimate 
language features.  Some flavor of  property (or of a certain 
other proposal which was a mimicry of C# properties... I was in 
that camp) has been in the plan ever since.

I find the ongoing debate/discussion of  property and -property 
to be... well, moot.  But hey, I'm just one crazy among an army 
of crazies.

-- Chris NS
Jul 16 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I'm another who is /vehemently/ against the utter
idiocy that is the -property switch.

I wonder: if we had another poll, a recall election
if you will, how many people who said "yes" the
first time would change their minds now?

I betcha it'd be quite a few.
Jul 16 2012
prev sibling next sibling parent "Chris NS" <ibisbasenji gmail.com> writes:
On Monday, 16 July 2012 at 23:13:54 UTC, Timon Gehr wrote:
 On 07/16/2012 10:55 AM, Chris NS wrote:
 Having been around long enough to remember when the ability to 
 call
 "foo()" as "foo" first appeared, I feel it necessary to point 
 out that
 this was *not* in fact a deliberate design, but rather a sort 
 of
 "accident" that arose out of D's first attempt at properties.

Afaik this first attempt was implemented roughly as designed. It is my understanding that property was added later in order to fix the introduced ambiguities.

Effectively yes, this is why I put "accident" in quotes. The accidental part was that it was inadvertently extended to functions that it should not have been. Free functions, for example, were not really supposed to be callable in that way... it has turned out to sometimes be a nice and useful thing, of course, but it wasn't exactly the goal at the time. The goal was simply class/struct/union member functions that could be swapped out for exposed fields, or vice versa, without any change in user code.
 It was the same "accident" loaded compiler release that gave 
 us pseudo-members --
 the precursors to UFCS.

I still wonder how that could possibly happen.

You, me, and everyone else. I recall even Walter being a bit surprised by it and reviewing his code afterward. The oddity was identified, but at the same time (almost-) everyone rather liked it and it stuck. At the time I was maintaining an extensive library of array extensions, a spiritual ancestor to today's std.algorithm and std.range. (None of that code is in Phobos, mind you, but it served a similar purpose.) It was sort of like finding a peppermint in an old coat pocket.
 The community discovered that these things were accepted by 
 the compiler
 -- which was actually against the language spec at the time -- 
 and
 further that the resulting code did the intuitively correct 
 thing.
 Response to the "accidents" being generally positive, it was 
 decided to
 work toward making them legitimate language features. Some 
 flavor of
  property (or of a certain other proposal which was a mimicry 
 of C#
 properties... I was in that camp)

That would certainly be more pretty -- OTOH it is hard to think of a way to extend this to UFCS that is as natural as what happens if everything is conflated in functions.

As I recall, that was essentially how the discussion went back then, too. I still like the C# style, personally, but I've found property to be plenty usable, and even admittedly a bet more terse.
 has been in the plan ever since.

 I find the ongoing debate/discussion of  property and 
 -property to be...
 well, moot. But hey, I'm just one crazy among an army of 
 crazies.

Well, this newsgroup has the property that the stuff that is actually important is usually unilaterally agreed upon rather quickly. :o)

Yeah... usually. ;) I rarely speak up anymore, since I just don't have the time to commit to proving concepts and whatnot anymore. "I'm old, Dean. So very old." I remember proposing a foreach statement (opApply was Walter's idea, though). I also remember the horror that was the 'instance' keyword... man do I ever love that beautiful !() operator now, no matter what anyone else says about it. Ultimately, I am quite satisfied with it all, even if the occasional dead horse takes a beating. I just find it strange that there's such heated debate over something that had seemed so settled. Which, I suppose, might just be an indicator that it isn't settled after all, eh? -- Chris NS
Jul 16 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 15 Jul 2012 19:17:11 +0200
schrieb Philippe Sigaud <philippe.sigaud gmail.com>:

 On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
 I see from this other discussions that it looks like 2.059 ( or
 maybe 2.060) does support something like 3.cm().   Not sure from
 the discussion if it would also accept 3.cm as in the xtext/xtend
 example.


Hi Jay, I had a little fun with coding a units (SI units) system in D and pushed an incomplete version on Github a few weeks ago: https://github.com/PhilippeSigaud/Units It allows things like: auto distance = 100.km; auto speed = 120.km/hour; auto timeToDestination = distance/speed; // timeToDest is a time (seconds) The version on Github is grossly limited (it's just a sketch), but it gives an idea of what's possible. My goal is to code a generic unit system generator, given user inputs such as a list of units and sub-units. cheers, Philippe

Sounds fun. I mean, it makes me happy to see code written like this instead of Distance distance = new Kilometers(100); Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new Hours(1)); :D -- Marco
Jul 18 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 18 July 2012 at 07:30:10 UTC, Marco Leise wrote:
 Am Sun, 15 Jul 2012 19:17:11 +0200
 schrieb Philippe Sigaud <philippe.sigaud gmail.com>:
 […]
 auto distance = 100.km;
 auto speed = 120.km/hour;
 
 auto timeToDestination = distance/speed; // timeToDest is a 
 time (seconds)
 
 The version on Github is grossly limited (it's just a sketch), 
 but it gives
 an idea of what's possible. My goal is to code a generic unit 
 system
 generator, given user inputs such as a list of units and 
 sub-units.
 
 […]

Sounds fun. I mean, it makes me happy to see code written like this instead of Distance distance = new Kilometers(100); Speed speed = Speed.fromDistanceByTime(new Kilometers(120), new Hours(1));

I find multiplication to read much more natural: --- enum km = kilo * meter; auto distance = 100.0 * km; auto speed = 100.0 * km / hour; auto timeToDest = distance / speed; --- See http://klickverbot.at/code/units/ for a slightly neglected implementation of this scheme. It supports stuff like defining new units with arbitrary (potentially runtime) conversion factors, properly typechecked affine units (think degrees celsius), etc. – but any error messages and symbol names will probably look like if the compiler had a seizure. David
Jul 18 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 16 July 2012 at 23:18:10 UTC, Adam D. Ruppe wrote:
 I'm another who is /vehemently/ against the utter
 idiocy that is the -property switch.

Arguments! Yay!
Jul 18 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:
 Arguments! Yay!

I've gone over this a dozen times on the group and on bugzilla, and I'm kinda sick of repeating it. -property breaks craploads of code. That's a huge negative, and nobody has even come close to countering that. "-property will be the standard" is utterly worthless, yet that's really the only thing I see brought up again. The other most common thing is "I don't like how writeln = 10 looks". Easy response: then don't write that. If you're going to break code because someone might write something you find ugly - note this is different than the arguments people like Crockford make about, say, Javascript's ==, which he argues is a bug 95% of the time you see it, this is just "I don't like how that looks". But if we're going to let the possibility for subjective ugliness be justification for BREAKING CODE, I can't stress that enough, we might as well just nuke the whole language. BTW, a common fallacy I also here is bringing up the edge cases like returning a delegate in a property. Two points: 1) That has *nothing* to do with syntax. The property decoration takes care of that, regardless of syntax. Why do we have to break a common case to fix an edge case.... especially when we /can/ have our cake and eat it too? 2) -property doesn't even get that right anyway. Not kidding, try it. -property might as well be renamed -break-my-code-and- give-me-ABSOLUTELY-NOTHING-in-return. Why, why would we ever consent to having that standard?
Jul 18 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 18 July 2012 at 12:30:46 UTC, Adam D. Ruppe wrote:
 2) -property doesn't even get that right anyway. Not kidding,
 try it. -property might as well be renamed -break-my-code-and-
 give-me-ABSOLUTELY-NOTHING-in-return.

 Why, why would we ever consent to having that standard?

I actually tend to agree with this part – I see -property more like an experiment help determining the behavior we want to make the default with real-world testing. We should definitely try to fix/improve the implementation of -property before we consider to make it the default. But without it, the discussion might have never gotten to the point where we are now, so I still consider it a success. David
Jul 18 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 7/18/2012 5:30 AM, Adam D. Ruppe wrote:
 On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:
 Arguments! Yay!

I've gone over this a dozen times on the group and on bugzilla, and I'm kinda sick of repeating it. -property breaks craploads of code. That's a huge negative, and nobody has even come close to countering that. "-property will be the standard" is utterly worthless, yet that's really the only thing I see brought up again.

The clear argument for me is that it must be trivial to take an existing member variable and change it to a property function pair _and vice versa_. If someone has property int foo() and property void foo(int) as members of a class and call sites add (), then yanking those back to just int foo; will fail, badly. So that must be explicitly disallowed. THAT is the argument for enforcing the lack of parens after properties, imho. The other bits about non- property functions is significantly less important as far as I'm concerned. My 2 cents, Brad
Jul 18 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 19 July 2012 at 02:57:05 UTC, Brad Roberts wrote:
 The clear argument for me is that it must be trivial to take an 
 existing member variable and change it to a property
 function pair _and vice versa_.

I can see some value in that.
 The other bits about non- property
 functions is significantly less important as far as I'm 
 concerned.

Question to everybody: how would you feel about this compromise: the strictness is opt in. So, if you don't use property, you get the status quo. These functions can be called either way, but if there's ambiguity, it tends toward treating them as a function. If you do use property, it becomes strict. This would cover your concerns while keeping the dual-syntax benefits, and it minimizes code breakage of existing stuff. It'd also discourage a lot of the questions of to property or not to property, since you can just ask "is it a real property" without falsely marking stuff for UFCS chaining or whatever. It'd save me a lot of headaches on my range.empty's too. If we switch to this compromise position, I'm about 98% sure I'd vote yes (would have to actually try it to be certain).
Jul 18 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--f46d042a0d672f2a6d04c5420929
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Marco:

 auto distance =3D 100.km;
 auto speed =3D 120.km/hour;



 Sounds fun. I mean, it makes me happy to see code written like this


 Distance distance =3D new Kilometers(100);
 Speed speed =3D Speed.fromDistanceByTime(new Kilometers(120), new


Yeah, that was exactly one of my goals :) David:
 I find multiplication to read much more natural:
 ---
 enum km =3D kilo * meter;

 auto distance =3D 100.0 * km;
 auto speed =3D 100.0 * km / hour;

 auto timeToDest =3D distance / speed;
 ---

This is good too. I have code that autogenerate the SI-prefixed versions (not on Github, I should clean it and push), but thought about offering prefix functions by themselves. Hmm, looking at it, I guess kilo is just 1000 as an enum in your code? That's a good idea. Anyway, multiplication is good, I just looked for an excuse to play with UFCS :)
 See http://klickverbot.at/code/units/ for a slightly neglected

with arbitrary (potentially runtime) conversion factors, properly typechecked affine units (think degrees celsius), etc. Ah good. I remembered someone posting something on units-checking, but couldn't find the message. I also have something on celsius/kelvin and wondered if I needed to go beyond affine, to fully generalize the concept. Btw, is =C2=B0C substraction authorized with your module, or multiplication= ? I wondered what to forbid and what to authorize. And I (re)discovered while browsing Wikipedia the numerous temperature units I saw at school 15 years ago :)
 =E2=80=93 but any error messages and symbol names will probably look like=

compiler had a seizure. why? --f46d042a0d672f2a6d04c5420929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p>Marco:</p> <p>&gt;&gt;&gt; auto distance =3D <a href=3D"http://100.km">100.km</a>;<br> &gt;&gt;&gt; auto speed =3D <a href=3D"http://120.km/hour">120.km/hour</a>;= </p> <p>&gt;&gt; Sounds fun. I mean, it makes me happy to see code written like = this instead of<br> &gt;&gt; Distance distance =3D new Kilometers(100);<br> &gt;&gt; Speed speed =3D Speed.fromDistanceByTime(new Kilometers(120), new = Hours(1));</p> <p>Yeah, that was exactly one of my goals :)<br></p> <p>David:<br></p> <p>&gt; I find multiplication to read much more natural:<br> &gt; ---<br> &gt; enum km =3D kilo * meter;<br> &gt;<br> &gt; auto distance =3D 100.0 * km;<br> &gt; auto speed =3D 100.0 * km / hour;<br> &gt;<br> &gt; auto timeToDest =3D distance / speed;<br> &gt; ---</p> <p>This is good too. I have code that autogenerate the SI-prefixed versions= (not on Github, I should clean it and push), but thought about offering pr= efix functions by themselves. Hmm, looking at it, I guess kilo is just 1000= as an enum in your code? That&#39;s a good idea.</p> <p>Anyway, multiplication is good, I just looked for an excuse to play with= UFCS :)<br><br></p> <p>&gt; See <a href=3D"http://klickverbot.at/code/units/">http://klickverbo= t.at/code/units/</a> for a slightly neglected implementation of this scheme= . It supports stuff like defining new units with arbitrary (potentially run= time) conversion factors, properly typechecked affine units (think degrees = celsius), etc.</p> <p>Ah good. I remembered someone posting something on units-checking, but c= ouldn&#39;t find the message. I also have something on celsius/kelvin and w= ondered if I needed to go beyond affine, to fully generalize the concept.</= p> <p>Btw, is =C2=B0C substraction authorized with your module, or multiplicat= ion? I wondered what to forbid and what to authorize.</p> <p>And I (re)discovered while browsing Wikipedia the numerous temperature u= nits I saw at school 15 years ago :)<br></p> <p>&gt; =E2=80=93 but any error messages and symbol names will probably loo= k like if the compiler had a seizure.</p> <p>why?</p> --f46d042a0d672f2a6d04c5420929--
Jul 20 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 20 July 2012 at 12:28:52 UTC, Philippe Sigaud wrote:
 Hmm, looking at it, I guess kilo is just
 1000 as an enum in your code? That's a good idea.

Sorry, that should have been »kilo!gram«. It actually creates a new unit with a conversion factor of 1000 relative to the base unit (well, it does a few more things to handle cases like kilo!(milli!meter)), with the point being that the quantities are actually stored in memory "verbatim", i.e. without being normalized to e.g. SI units. Making »kilo * gram« work would be easy, but I decided it could lead to confusing situations. David
Jul 20 2012
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 Sorry, that should have been =C2=BBkilo!gram=C2=AB. It actually creates a=

 with tbua conversion factor of 1000 relative to the base unit (well, it d=

 few more things to handle cases like kilo!(milli!meter)), with the point
 being that the quantities are actually stored in memory "verbatim", i.e.
 without being normalized to e.g. SI units. Making =C2=BBkilo * gram=C2=AB=

 be easy, but I decided it could lead to confusing situations.

At one time, I wanted to make kilo a factory function that would do the same transformation as your kilo!gram (that is, kilo(milli(gramm)) would in fact return a gram), but I found the style to be too different from the rest of the code (with value.kg and such). Btw, how do you handle the fact that in SI, the mass unit is the kilogram and not the gram?
Jul 20 2012