Re: ufcs and integer params
Sorry, that should have been »kilo!gram«. It actually creates a new unit with tbua 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. 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?
Re: ufcs and integer params
Marco: auto distance = 100.km; auto speed = 120.km/hour; 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)); Yeah, that was exactly one of my goals :) David: 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; --- 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 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. 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 °C 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 :) – but any error messages and symbol names will probably look like if the compiler had a seizure. why?
Re: ufcs and integer params
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
Re: ufcs and integer params
Am Sun, 15 Jul 2012 19:17:11 +0200 schrieb Philippe Sigaud philippe.sig...@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
Re: ufcs and integer params
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!
Re: ufcs and integer params
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.sig...@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
Re: ufcs and integer params
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?
Re: ufcs and integer params
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
Re: ufcs and integer params
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
Re: ufcs and integer params
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).
Re: ufcs and integer params
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
Re: ufcs and integer params
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
Re: ufcs and integer params
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
Re: ufcs and integer params
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
Re: ufcs and integer params
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)
Re: ufcs and integer params
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.
Re: ufcs and integer params
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
Re: ufcs and integer params
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
Re: ufcs and integer params
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/smoniukqfxerutqrj...@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'?
Re: ufcs and integer params
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/smoniukqfxerutqrj...@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
Re: ufcs and integer params
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
Re: ufcs and integer params
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.
Re: ufcs and integer params
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/smoniukqfxerutqrj...@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.
Re: ufcs and integer params
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
Re: ufcs and integer params
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.)
Re: ufcs and integer params
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
Re: ufcs and integer params
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.
Re: ufcs and integer params
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.
Re: ufcs and integer params
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
Re: ufcs and integer params
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?
ufcs and integer params
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.Darticle_id=97661
Re: ufcs and integer params
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/smoniukqfxerutqrj...@forum.dlang.org
Re: ufcs and integer params
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/smoniukqfxerutqrj...@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
