On 4/26/13 4:15 PM, bearophile wrote:
Tyro[17]:
While flip2 does:
flip2!foo(a, b, c) === foo(b, a, c)
flip2!foo(a, b, c, d) === foo(b, a, c, d)
and this rotate
Really? Just swapping the first two arguments and leaving the others at
their place is for a rotate?
Actually, by brain
On 4/26/13 5:09 PM, Tyro[17] wrote:
On 4/26/13 4:15 PM, bearophile wrote:
Tyro[17]:
While flip2 does:
flip2!foo(a, b, c) === foo(b, a, c)
flip2!foo(a, b, c, d) === foo(b, a, c, d)
and this rotate
Really? Just swapping the first two arguments and leaving the others at
their place is
Tyro[17]:
With that clarification, I just have one more question, since
flip does what is intuitively implied by a reverse function
OK, better to name it reversedArgs :-)
and flip2 does what is intuitively implied by a flip function,
flip2 swaps just the fist two arguments and leaves the
writeln is able to write a whole range:
import std.stdio, std.algorithm, std.range;
void main() {
10.iota.map!(x = x ^^ 2).writeln;
}
Output:
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
- - - - - - - - - - - - - - - -
But if you want to format the range in some way you have to
change the
This is not a real use case because the reduce!() of Phobos will
be fixed for UCFS, but sometimes you can't swap the arguments of
a function:
import std.stdio, std.algorithm, std.range;
/// flip2!foo(a, b, c...) === foo(b, a, c...)
template flip2(alias callable) {
auto flip2(T2,
Doesn't binaryReverseArgs in std.functional already do this? Flip
is a much, much better name though.
the output of a function. It's useful for normal code as
well as UFCS.
string temp = myFun();
temp.writeln;
result ~= temp ~ \n;
On Thursday, 25 April 2013 at 16:20:39 UTC, ixid wrote:
Doesn't binaryReverseArgs in std.functional already do this?
Right, it's the flip I have suggested here. My flip2 is a little
different. I will think about this.
Though I still think write functions passing on the data would
be
On 04/25/2013 05:09 PM, bearophile wrote:
...
What do you think?
...
I think what you call flip2 should be called flip.
On Wednesday, 27 February 2013 at 23:43:49 UTC, bearophile wrote:
void main() {
auto a = [0,1,2,3,4,5,6,7,8,9][5 .. 2];
}
I tried it too, hoping for something like
[5,4,3]
or at least
[4,3,2] (== [0,1,2,3,4,5,6,7,8,9][2..5].reverse)
This command:
writeln(iota(10).cycle()[5..2].take(4));
print:
[5, 6, 7, 8]
Shouldn't [5..2] slice throw a compile/runtime error?
Andrea Fontana:
writeln(iota(10).cycle()[5..2].take(4));
print:
[5, 6, 7, 8]
Shouldn't [5..2] slice throw a compile/runtime error?
Please file it in bugzilla.
The opSlice of cycle() lacks those pre-conditions or tests, and
there are not enough unittests in Phobos to catch this simple
On Wednesday, February 27, 2013 23:48:05 bearophile wrote:
Andrea Fontana:
writeln(iota(10).cycle()[5..2].take(4));
print:
[5, 6, 7, 8]
Shouldn't [5..2] slice throw a compile/runtime error?
Please file it in bugzilla.
The opSlice of cycle() lacks those pre-conditions or
On Wednesday, 27 February 2013 at 22:48:06 UTC, bearophile wrote:
Andrea Fontana:
writeln(iota(10).cycle()[5..2].take(4));
print:
[5, 6, 7, 8]
Shouldn't [5..2] slice throw a compile/runtime error?
Please file it in bugzilla.
The opSlice of cycle() lacks those pre-conditions or tests,
Andrea Fontana:
Done!
I was about to file it myself, so I have added a bit more meat to
your bug report.
Bye,
bearophile
Jonathan M Davis:
What it should be doing is using version(assert) to throw a
RangeError if the
arguments are invalid, but the addition of version(assert) is
quite recent
(previously, the best that could have been done was to assert).
Do you mean something like this?
auto opSlice(size_t i,
auto opSlice(size_t i, size_t j)
in {
assert(i = j, some message here);
} body {
auto retval = this.save;
retval._index += i;
return takeExactly(retval, j - i);
}
This is the bug opened by Andrea Fontana for this thread:
http://d.puremagic.com/issues/show_bug.cgi?id=9612
At
To do the same with user-defined structures time ago I have
suggested this, that is currently closed waiting for a better
solution:
What I meant to say is that if the assert(i = j) is inside the
pre-condition then there's a hope to run it at compile time
introducing some new trick inside the
On Thursday, February 28, 2013 00:46:56 bearophile wrote:
To do the same with user-defined structures time ago I have
suggested this, that is currently closed waiting for a better
solution:
What I meant to say is that if the assert(i = j) is inside the
pre-condition then there's a hope
On Thursday, February 28, 2013 00:35:08 bearophile wrote:
Jonathan M Davis:
What it should be doing is using version(assert) to throw a
RangeError if the
arguments are invalid, but the addition of version(assert) is
quite recent
(previously, the best that could have been done was to
Jonathan M Davis:
Because then it more closely matches how arrays work. The only
part that
doesn't is that it's fully tied to -release rather than
-noboundschecked.
I see, thank you.
Honestly, I think that that's a complete pipe dream anyway,
I will keep dreaming for some more decades.
Unfortunately, opDispatch [silently] takes precedence over
UFCS. I don't suppose there's any way to make a UFCS function call
override opDispatch without either ditching UFCS or altering/removing
the opDispatch itself?
On 2013-01-16, 22:02, Nick Sabalausky wrote:
Unfortunately, opDispatch [silently] takes precedence over
UFCS. I don't suppose there's any way to make a UFCS function call
override opDispatch without either ditching UFCS or altering/removing
the opDispatch itself?
Only solution I know
Thank you guys. I can't believe that haven't thought of that.
I still feel that this is rather odd though. I would expect to be
able to use UFCS in the scope that imports those libraries.
Though I can definitely see how that might lead to obscure bugs.
On Tuesday, 16 October 2012 at 17:07:36
that is not what UFCS does.
but as soon as you import some other
modules, authors of which also consider UFCS operators a good idea,
Who has stated that? It just does not make sense to explicitly ban
them, as they are not special.
everything breaks including namespace conflict
The usual disambiguation
On 10/14/2012 09:14 AM, Maxim Fomin wrote:
On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote:
Actually, it seems that alias this has precedence over UFCS. So, a
free function opUnary wouldn't ever suit better than an actual method
opUnary of the thing referred to by that alias
On Wednesday, 17 October 2012 at 10:24:57 UTC, Artur Skawina
wrote:
Operator overloading can be abused - that's an obvious and well
known fact. But that
same feature can also be very useful, if used right. Worrying
about UFCS problems in
the context of op-overloading needlessly complicates
methods are special functions and not treating them as candidates for
UFCS does make more sense.
I do not understand how an operation that happens to be called '+' is
fundamentally different from an operation that is called 'add'.
The first one is an operator, which sometimes, may be rewritten
to
... and then add methods
Which is still not correct, because that is not what UFCS does.
It is not correct as long as you cavil at lexis, however the
statement has room for correction.
but as soon as you import some other
modules, authors of which also consider UFCS operators a good
idea,
Who
On 10/17/12 12:46, Timon Gehr wrote:
On 10/15/2012 01:00 PM, Artur Skawina wrote:
...
An overloaded operator is just another normal method; you get the same type
of
problems when dealing with normal methods - eg in types having an alias
this -
an UFCS method must take precedence over
On Tuesday, 16 October 2012 at 00:50:54 UTC, Artur Skawina wrote:
Actually, I'm not really in any camp. UFCS has several obvious
problems plus likely
quite a few more subtle ones. Ignoring the issues does not make
them go away and
the
some-compiler-happens-to-implement-it-like-that-today
On Monday, 15 October 2012 at 09:33:23 UTC, Maxim Fomin wrote:
---foo.d---
struct A
{
int i;
alias i this;
}
---bar.d---
int opUnary(string T)(A a) { ... }
...
{
++a;
}
---
I. i is incremented, opUnary is not called. However opUnary
matches better to the actual type and if it
On Tuesday, 16 October 2012 at 16:12:06 UTC, Michael wrote:
void main() {
import std.range, std.stdio;
The problem is that UFCS only works on functions in the global
scope. The import inside a function makes them local, so it
doesn't consider them in it.
This is apparently
happens
if there are two conflict entities and one of them has higher
priority than another. In case of UFCS depending on design two
types of hijacks may happen:
- either newly created free UFCS function hijacks existing method
- or newly created method hijacks existing free function.
Currently D
On Tuesday, October 16, 2012 18:28:14 Adam D. Ruppe wrote:
On Tuesday, 16 October 2012 at 16:12:06 UTC, Michael wrote:
void main() {
import std.range, std.stdio;
The problem is that UFCS only works on functions in the global
scope. The import inside a function makes them local, so
On Sunday, 14 October 2012 at 19:50:54 UTC, Artur Skawina wrote:
On 10/14/12 08:13, Maxim Fomin wrote:
The only mentioned reason is to allow writing operator
overloading methods outside type scope - just because somebody
(currently two people) consider it logical to broaden UFCS
usage.
It's
cannot and must not ever hijack, i.e. modify
existing functionality of a type. Free functions should only be
able to add new functionality to a type. This is what currently
happens with alias this vs free function which is accessed
through UFCS:
snip
This shows current behavior. The issue
it logical to broaden UFCS usage.
It's more than two people... Also, it's not about broadening UFCS usage,
it's about making UFCS work properly.
When UFCS was added to the language its purpose was to call free functions
pretending you are invoking methods. It does it job pretty well
On Monday, 15 October 2012 at 11:01:13 UTC, Artur Skawina wrote:
UFCS has pros and cons. I could agree that it has problems and
should be removed
from the language completely. But if the feature is there, it
should work, w/o any
unnecessary special cases.
Special cases would be created
On 10/15/12 17:49, Maxim Fomin wrote:
On Monday, 15 October 2012 at 11:01:13 UTC, Artur Skawina wrote:
UFCS has pros and cons. I could agree that it has problems and should be
removed
from the language completely. But if the feature is there, it should work,
w/o any
unnecessary special
outside type scope - just because somebody (currently two people)
consider it logical to broaden UFCS usage. This doesn't solve ay
practical issue.
On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote:
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined type,
then:
++var
gets rewritten as:
var.opUnary!++()
Not always. If user-defined type has an alias this to integer
member, than
than alias this, dmd will issue
call to that function, it it see its declaration.
Actually, it seems that alias this has precedence over UFCS. So,
a free function opUnary wouldn't ever suit better than an actual
method opUnary of the thing referred to by that alias this.
and not treating them as
candidates for
UFCS does make more sense.
I do not understand how an operation that happens to be called
'+' is fundamentally different from an operation that is called
'add'.
The first one is an operator, which sometimes, may be rewritten
to function call, the second one
On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote:
Actually, it seems that alias this has precedence over UFCS.
So, a free function opUnary wouldn't ever suit better than an
actual method opUnary of the thing referred to by that alias
this.
http://dpaste.dzfl.pl/d0a4431d
Free function
On 10/14/12 08:13, Maxim Fomin wrote:
The only mentioned reason is to allow writing operator overloading methods
outside type scope - just because somebody (currently two people) consider it
logical to broaden UFCS usage.
It's more than two people... Also, it's not about broadening UFCS
functionality of a type. Free functions should only be
able to add new functionality to a type. This is what currently
happens with alias this vs free function which is accessed
through UFCS:
struct B
{
void fun()
{
writeln(B.fun());
}
}
struct A
{
B b;
alias b
'
I'd expect the lines tagged #3 and #4 to be rewritten by the
compiler like so:
ms.opUnary!++();
MyStruct ms3 = ms.opBinary!+(1);
So, the inability to do operator overloading though UFCS must be
a compiler bug, right?
On Saturday, 13 October 2012 at 08:36:19 UTC, Tommi wrote:
Quote from TDPL: D’s approach to operator overloading is
simple: whenever at least one participant in an operator
expression is of user-defined type, the compiler rewrites the
expression into a regular method call with a specific name.
On Saturday, October 13, 2012 11:06:27 Jakob Ovrum wrote:
On Saturday, 13 October 2012 at 08:36:19 UTC, Tommi wrote:
Quote from TDPL: D’s approach to operator overloading is
simple: whenever at least one participant in an operator
expression is of user-defined type, the compiler rewrites
On Saturday, 13 October 2012 at 09:06:28 UTC, Jakob Ovrum wrote:
Do note that this says *method* call. Your example doesn't use
methods. Hence, the current state of operator overloading is
consistent with TDPL.
I don't agree with the last sentence. According to TDPL:
1) whenever at least one
that as:
.opUnary!++(var);
Just because the overloaded operator is rewritten into a method call
underneath the hood doesn't mean that the UFCS rewrite also applies. The
transformation of an operator to a method or a UFCS call to a free function is
done _once_. You don't get both. It is most definitely _by
On Saturday, 13 October 2012 at 09:50:05 UTC, Jonathan M Davis
wrote:
It is most definitely _by design_ that you cannot
overload operators except as member functions.
I don't understand this design choice then. I don't see any
problem in allowing UFCS operators. Because of the way UFCS
works
problem in allowing UFCS operators. Because of the way UFCS
works, it's guaranteed that there can't be any operator
hijacking.
I think implementing UFCS operator overloading is problematic.
Firstly, you want to put this language addition too far.
Secondly, compiler needs to know whether operator
On Saturday, 13 October 2012 at 11:50:40 UTC, Maxim Fomin wrote:
I think implementing UFCS operator overloading is problematic.
Firstly, you want to put this language addition too far.
I don't see this as taking UFCS functionality further. Rather,
I think it's simply more logical
On Saturday, 13 October 2012 at 15:06:14 UTC, Tommi wrote:
On Saturday, 13 October 2012 at 11:50:40 UTC, Maxim Fomin wrote:
I think implementing UFCS operator overloading is problematic.
Firstly, you want to put this language addition too far.
I don't see this as taking UFCS functionality
On Saturday, 13 October 2012 at 16:02:25 UTC, Maxim Fomin wrote:
From my point of view operator overloading methods are
special functions and not treating them as candidates for
UFCS does make more sense.
I can think of only one thing that makes custom operator methods
special or different
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined type,
then:
++var
gets rewritten as:
var.opUnary!++()
Thus, it would be very logical to assume that it doesn't matter
whether you write:
++var
...or, write the following instead:
On 10/13/2012 06:02 PM, Maxim Fomin wrote:
...
Different groups of people have different mind and same things produce
different sense on them. From my point of view operator overloading
methods are special functions and not treating them as candidates for
UFCS does make more sense.
I do
will be
translated into another where it will then be assumed that the new language
construct is using syntactic sugar such as UFCS, because _all_ of that
syntactic sugar must be lowered to code which _isn't_ syntactic sugar anymore.
It would be far more expensive to have to continually make passes
On 10/13/2012 10:15 PM, Jonathan M Davis wrote:
...
construct is using syntactic sugar such as UFCS, because _all_ of that
syntactic sugar must be lowered to code which _isn't_ syntactic sugar anymore.
That is not what lowering means.
It would be far more expensive to have to continually
On Sun, Oct 14, 2012 at 12:12:01AM +0200, Timon Gehr wrote:
On 10/13/2012 10:15 PM, Jonathan M Davis wrote:
[...]
but they _aren't_ mixed and they will _never_ be mixed. If it had
_ever_ been intended that it be possible to overload operators as
free functions, then we'd simply have made it so
? Or was it just a matter of not being implemented because
nobody thought about it at the time?
T
Afaik free-function operator overloads (but not in the context of
UFCS) were considered and turned down because D did not want to get
amidst discussions about adding Koenig lookup. UFCS does not do Koenig
Hi,
I'd like to write a function for a vector template which
basically looks like
struct Vec(T, size_t size) {
T[size] e;
}
This template has a few properties with very common names like x,
y, z, etc. To avoid mistakes I'd like to write a template
constraint for UFCS functions so
a template constraint for UFCS
functions so it accepts any instance of the Vec template, but nothing
else. Something in the gist of
auto innerProduct(T)(const T v1, const T v2) if(is(T == Vec)) {
}
How can I do this?
I am doing it in gl3n like this:
https://github.com/Dav1dde/gl3n/blob/master/gl3n
properties with very common names like
x, y, z,
etc. To avoid mistakes I'd like to write a template constraint
for UFCS
functions so it accepts any instance of the Vec template, but
nothing
else. Something in the gist of
auto innerProduct(T)(const T v1, const T v2) if(is(T == Vec)) {
}
How
Rene Zwanenburg:
How can I do this?
One possible solution:
struct Vec(T, size_t size) {
T[size] e;
}
void innerProduct(T, size_t n)(const Vec!(T, n) v1,
const Vec!(T, n) v2) {}
void main() {
Vec!(int, 3) v1, v2;
innerProduct(v1, v2);
}
(While
That's actually quite straightforward. I forgot how well D's type
deduction works.
Thanks
On Thursday, 13 September 2012 at 11:01:18 UTC, bearophile wrote:
Rene Zwanenburg:
How can I do this?
One possible solution:
struct Vec(T, size_t size) {
T[size] e;
}
void innerProduct(T,
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,
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
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
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
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!
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 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.
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
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,
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).
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
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
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
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
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
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.
. 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
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
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
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
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
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
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
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
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
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
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.
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
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
. 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
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.
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
301 - 400 of 412 matches
Mail list logo
