On 01/01/2012 08:17 AM, Don wrote:
On 31.12.2011 16:26, Timon Gehr wrote:
On 12/31/2011 12:13 PM, Don wrote:
On 31.12.2011 02:27, so wrote:
On Sat, 31 Dec 2011 02:40:24 +0200, Don nos...@nospam.com wrote:
I think: there are cases when named parameters are beneficial. There
are cases where
On 31.12.2011 16:58, Timon Gehr wrote:
On 12/31/2011 12:51 PM, Don wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
In case the function is used for code generation, it can get
rid of one level of indentation.
string generate(string x) = mixin(X!q{
@(x) = 2;
});
That just makes it look even
On 01/01/2012 04:39 PM, Don wrote:
On 31.12.2011 16:58, Timon Gehr wrote:
On 12/31/2011 12:51 PM, Don wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
In case the function is used for code generation, it can get
rid of one level of indentation.
string generate(string x) = mixin(X!q{
@(x) = 2;
On 31.12.2011 02:27, so wrote:
On Sat, 31 Dec 2011 02:40:24 +0200, Don nos...@nospam.com wrote:
I think: there are cases when named parameters are beneficial. There
are cases where they are detrimental.
Is it possible to get the first, without the second, and without much
complexity?
If we
On 31.12.2011 02:37, so wrote:
On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis
jmdavisp...@gmx.com wrote:
Introducing named arguments makes a function's parameters part of the
API and
introduces yet another point where code breakage can occur due to code
changes. And that is a _very_
On 30.12.2011 01:13, Timon Gehr wrote:
On 12/29/2011 10:19 AM, Don wrote:
On 28.12.2011 17:41, Jacob Carlborg wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
On 12/31/2011 12:13 PM, Don wrote:
On 31.12.2011 02:27, so wrote:
On Sat, 31 Dec 2011 02:40:24 +0200, Don nos...@nospam.com wrote:
I think: there are cases when named parameters are beneficial. There
are cases where they are detrimental.
Is it possible to get the first, without the second,
On 12/31/2011 12:51 PM, Don wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
In case the function is used for code generation, it can get
rid of one level of indentation.
string generate(string x) = mixin(X!q{
@(x) = 2;
});
That just makes it look even more like Perl. The return statement is not
On 31.12.2011 16:26, Timon Gehr wrote:
On 12/31/2011 12:13 PM, Don wrote:
On 31.12.2011 02:27, so wrote:
On Sat, 31 Dec 2011 02:40:24 +0200, Don nos...@nospam.com wrote:
I think: there are cases when named parameters are beneficial. There
are cases where they are detrimental.
Is it possible
Andrei Alexandrescu wrote:
is part of writing programs
If libraries from more than one author are used with named parameters,
inconsistencies in the naming will be a normal problem.
For example: a boolean parameter for generating ouput might be named
differently in two libraries as `print'
On 30.12.2011 07:36, Andrei Alexandrescu wrote:
On 12/30/11 12:25 AM, Derek wrote:
On Fri, 30 Dec 2011 16:22:49 +1100, Don nos...@nospam.com wrote:
Some names are better than others. But are they part of the API?
That's the issue.
Yes, that is an issue.
Often, parameter names (such as in
On Sat, 31 Dec 2011 02:40:24 +0200, Don nos...@nospam.com wrote:
I think: there are cases when named parameters are beneficial. There are
cases where they are detrimental.
Is it possible to get the first, without the second, and without much
complexity?
If we keep rules simple as possible
On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Introducing named arguments makes a function's parameters part of the
API and
introduces yet another point where code breakage can occur due to code
changes. And that is a _very_ negative aspect of named
On 29.12.2011 02:02, so wrote:
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
The moment NP by default is introduced is the moment all parameter
names in all
On 29.12.2011 04:48, David Nadlinger wrote:
On 12/29/11 3:46 AM, Timon Gehr wrote:
My point is, without named arguments you can improve the names at any
time. With named arguments, you are stuck and have to get it right
upfront.
My point is, without positional arguments you can improve the
Naming is much less error-prone, then positioning, because change in
position is much less obvious (especially for parameters of the same
type).
When you write a class or a function you also need to come up with a
name, but you don't think of it as being forced to think ahead.
You'll always need
On Thu, 29 Dec 2011 19:07:17 +1100, Don nos...@nospam.com wrote:
sin(real x);
sin(real theta);
The argument name is *completely* irrelevant. That shouldn't be part of
the interface.
I have a really really bad taste in my mouth from named arguments in COM.
Were you forced to use named
On Thu, 29 Dec 2011 19:08:36 +1100, Don nos...@nospam.com wrote:
On 29.12.2011 04:48, David Nadlinger wrote:
On 12/29/11 3:46 AM, Timon Gehr wrote:
My point is, without named arguments you can improve the names at any
time. With named arguments, you are stuck and have to get it right
upfront.
On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:
On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
(while I have not written a significant amount of functional-style
code in Javascript)
It looks fine if you use named functions or a little whitespace
around the literals (same as
On 28.12.2011 17:41, Jacob Carlborg wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Great! =)
What about making = syntax available to
On 29.12.2011 09:39, Derek wrote:
On Thu, 29 Dec 2011 19:08:36 +1100, Don nos...@nospam.com wrote:
On 29.12.2011 04:48, David Nadlinger wrote:
On 12/29/11 3:46 AM, Timon Gehr wrote:
My point is, without named arguments you can improve the names at any
time. With named arguments, you are
On 29.12.2011 09:34, Derek wrote:
On Thu, 29 Dec 2011 19:07:17 +1100, Don nos...@nospam.com wrote:
sin(real x);
sin(real theta);
The argument name is *completely* irrelevant. That shouldn't be part
of the interface.
I have a really really bad taste in my mouth from named arguments in COM.
On 29-12-2011 14:07, Jacob Carlborg wrote:
On 2011-12-29 10:19, Don wrote:
On 28.12.2011 17:41, Jacob Carlborg wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
On Thursday, 29 December 2011 at 09:07:21 UTC, Max Samukha wrote:
it is obvious that JavaScript is unnecessarily noisy.
Meh, one man's music is another man's noise.
On Thu, 29 Dec 2011 11:48:13 +0200, Don nos...@nospam.com wrote:
I'm not aware of any languages where positional arguments are not
supported. The restrictions imposed by named arguments are a pure
superset of the restrictions imposed by positional arguments.
Don, it is a made up argument
On 29-12-2011 14:10, Alex Rønne Petersen wrote:
On 29-12-2011 14:07, Jacob Carlborg wrote:
On 2011-12-29 10:19, Don wrote:
On 28.12.2011 17:41, Jacob Carlborg wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
On 2011-12-29 10:19, Don wrote:
On 28.12.2011 17:41, Jacob Carlborg wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Great! =)
What
On 12/29/2011 3:07 AM, Don wrote:
sin(real x);
sin(real theta);
The argument name is *completely* irrelevant. That shouldn't be part
of the interface.
I have a really really bad taste in my mouth from named arguments in COM.
Great example... I can totally think that 'x', 'theta', 't',
On 2011-12-29 10:07, Max Samukha wrote:
On 12/29/2011 01:49 AM, Adam D. Ruppe wrote:
On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
(while I have not written a significant amount of functional-style
code in Javascript)
It looks fine if you use named functions or a little
On Thursday, December 29, 2011 18:49:51 so wrote:
When you change a parameter name, you change interfaces file and
documentation.
Your user will recompile/reread regardless, because you came up with a new
version.
Now with NP those that want to bother will edit their codes, he asked
for it.
On Fri, 30 Dec 2011 01:16:56 +1100, Mehrdad wfunct...@hotmail.com wrote:
On 12/29/2011 3:07 AM, Don wrote:
sin(real x);
sin(real theta);
The argument name is *completely* irrelevant. That shouldn't be part of
the interface.
I have a really really bad taste in my mouth from named arguments
Jacob Carlborg:
When you're implementing a lot of properties that basically just
forwards to the instance variables it can be really useful.
http://d.puremagic.com/issues/show_bug.cgi?id=7176
Bye,
bearophile
On 12/29/2011 10:19 AM, Don wrote:
On 28.12.2011 17:41, Jacob Carlborg wrote:
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Great! =)
What
On 29.12.2011 23:00, Derek wrote:
On Fri, 30 Dec 2011 01:16:56 +1100, Mehrdad wfunct...@hotmail.com wrote:
On 12/29/2011 3:07 AM, Don wrote:
sin(real x);
sin(real theta);
The argument name is *completely* irrelevant. That shouldn't be part
of the interface.
I have a really really bad taste
On Fri, 30 Dec 2011 16:22:49 +1100, Don nos...@nospam.com wrote:
Some names are better than others. But are they part of the API? That's
the issue.
Yes, that is an issue.
Often, parameter names (such as in sin(x)) are arbitrary and
meaningless. This is fundamental: the parameter names
On 12/30/11 12:25 AM, Derek wrote:
On Fri, 30 Dec 2011 16:22:49 +1100, Don nos...@nospam.com wrote:
Some names are better than others. But are they part of the API?
That's the issue.
Yes, that is an issue.
Often, parameter names (such as in sin(x)) are arbitrary and
meaningless. This is
On Wednesday, 28 December 2011 at 00:21:40 UTC, Jonathan M Davis
wrote:
On Tuesday, December 27, 2011 14:07:25 Jakob Ovrum wrote:
And it is indeed very important. It's one of the few syntax
woes
we have to deal with in D, it would be a shame to let the
benefits of std.algorithm and any other
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syntax uniformity and code
readability. So I think it's a bad idea.
On the
Am 27.12.2011, 16:11 Uhr, schrieb Andrei Alexandrescu
seewebsiteforem...@erdani.org:
On 12/27/11 4:51 AM, deadalnix wrote:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll
Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
Wouldn't it be great if Santa were to give us named arguments this year
too?
:)
Only if he hates me. But I guess that I'm in the minority around here in
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call site compared to calls
like this:
showWidget(true, false);
But I bet one day Walter Co. will have another phone
On 28/12/11 2:57 PM, Andrej Mitrovic wrote:
But I bet one day Walter Co. will have another phone conversation
and then magically we'll have named arguments the next day, without
asking the community about how it feels about the inclusion (e.g. just
like D1 deprecation, this lambda syntax, and
On 2011-12-27 15:27, Alex Rønne Petersen wrote:
On 27-12-2011 15:19, Alex Rønne Petersen wrote:
On 27-12-2011 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Awesome!
Now the only gripe I have left is
On 12/28/11 8:57 AM, Andrej Mitrovic wrote:
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call site compared to calls
like this:
showWidget(true, false);
But I
On 2011-12-27 22:53, Alex Rønne Petersen wrote:
On 27-12-2011 21:32, Jacob Carlborg wrote:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Now that's very cool. Does it work for
On 2011-12-27 23:18, Timon Gehr wrote:
On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:
On 27-12-2011 21:32, Jacob Carlborg wrote:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Now
On 2011-12-27 23:27, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Great! =)
What about making = syntax available to named functions as well?
class C{
private int
On 2011-12-28 13:54, bearophile wrote:
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syntax uniformity and code
readability. So
On 2011-12-28 14:18, Marco Leise wrote:
Am 28.12.2011, 01:22 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
Wouldn't it be great if Santa were to give us named arguments this
year too?
:)
Only if he hates me. But I guess that
On 2011-12-28 16:14, Peter Alexander wrote:
On 28/12/11 2:57 PM, Andrej Mitrovic wrote:
But I bet one day Walter Co. will have another phone conversation
and then magically we'll have named arguments the next day, without
asking the community about how it feels about the inclusion (e.g. just
Le 28/12/2011 13:54, bearophile a écrit :
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syntax uniformity and code
readability.
On 12/28/2011 05:59 PM, Jacob Carlborg wrote:
On 2011-12-28 13:54, bearophile wrote:
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases
On 12/28/2011 07:15 PM, deadalnix wrote:
The syntax to do such a thing is more verbose in javascript. So
definitively, this is a nice syntax, but this isn't that ground
breaking, and this isn't even required for people to use this type of
constructs.
People keep complaining about the
On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call site compared to calls
like this:
On 12/28/2011 09:25 PM, Jonathan M Davis wrote:
On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call
On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
I also don't think that they add much unless you have functions with way
too many parameters, and those sorts of functions shouldn't be
happening anyway. And I don't like the additional complication of the
possibility of reordering
On 2011-12-28 18:15, deadalnix wrote:
Le 28/12/2011 13:54, bearophile a écrit :
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases
On 12/28/2011 09:57 PM, Jonathan M Davis wrote:
On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
I also don't think that they add much unless you have functions with way
too many parameters, and those sorts of functions shouldn't be
happening anyway. And I don't like the additional
On 2011-12-28 18:54, Timon Gehr wrote:
On 12/28/2011 05:59 PM, Jacob Carlborg wrote:
On 2011-12-28 13:54, bearophile wrote:
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
On 2011-12-28 18:15, deadalnix wrote:
Le 28/12/2011 13:54, bearophile a écrit :
Timon Gehr:
= expr
should imo be a shorthand for
() = expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases
On Wed, 28 Dec 2011 22:57:32 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
I'd hate to have a function like
void func(float x, float y);
where calling it
func(1.0, 2.0);
and
func(y : 1.0, x : 2.0);
don't do the same thing. All of a sudden, I have to pay attention to what
names the
On 12/28/2011 11:34 PM, so wrote:
If you change anything in your interface, it is already a breaking
change.
That is why it is desirable to not let parameter names contribute to the
interface. Jonathan definitely has a point against making all parameters
named parameters by default.
From a
deadalnix:
bearophile:
In my opinion the most important reason for the introduction of
this anonymous function syntax is that it makes D functional-style
code (and generally code that uses lot of callbacks) less noisy,
so it makes it more easy to write and read.
Both argument are fallacy.
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 12/28/2011 11:34 PM, so wrote:
If you change anything in your interface, it is already a breaking
change.
That is why it is desirable to not let parameter names contribute to the
interface. Jonathan definitely has a
Jonathan M Davis:
The primary reason that I really don't like named arguments is the fact that
the names of the parameters become part of the API.
Sometimes I don't mind to make the names part of the API.
And as you remember we have suggested an idea adapted from Scala.
void foo(int x) {}
On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
(while I have not written a significant amount of
functional-style code in Javascript)
It looks fine if you use named functions or a little whitespace
around the literals (same as D!).
On 12/29/2011 12:29 AM, so wrote:
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 12/28/2011 11:34 PM, so wrote:
If you change anything in your interface, it is already a breaking
change.
That is why it is desirable to not let parameter names contribute to
the
On Wednesday, 28 December 2011 at 20:58:33 UTC, Jonathan M Davis
wrote:
Since they affect the API, they _do_ hurt
In my web.d, I support named and positional parameters for
remote calls.
I almost always use the positional parameters exactly because
they are not affected by name changes in the
Timon Gehr:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names for
their function parameters.
And this is a good thing :-) It helps you understand the function purpose
better.
Bye,
bearophile
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr timon.g...@gmx.ch wrote:
The moment NP by default is introduced is the moment all parameter names
in all libraries are set in stone.
This is completely false. NP affects only those that want to use it, no
one else. Again, no one.
It is just
On Thu, 29 Dec 2011 01:58:46 +0200, so s...@so.so wrote:
He doesn't need to remember, compiler does that for him but only for him
:)
As it turns out compiler don't give a damn about him either.
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr timon.g...@gmx.ch wrote:
The moment NP by default is introduced is the moment all parameter
names in all libraries are set in stone.
This is completely false. NP affects only those that want to use it,
no one
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
The moment NP by default is introduced is the moment all parameter
names in all libraries are set in stone.
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr timon.g...@gmx.ch wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names for
their function parameters.
And that's a bad thing, right?
Named parameters do
On Thu, 29 Dec 2011 12:02:28 +1100, so s...@so.so wrote:
Show me any library code from any language where library writer is not
already aware their argument names define their function.
Supporting example:
int find( T needle, T[] haystack)
As a side effect, it might even help prevent
On 12/29/2011 02:04 AM, Derek wrote:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr timon.g...@gmx.ch wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names
for their function parameters.
And that's a bad
On 12/29/2011 02:02 AM, so wrote:
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr timon.g...@gmx.ch wrote:
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
The moment NP by default is introduced is the moment all parameter
names in all
Timon Gehr:
On 12/29/2011 02:04 AM, Derek wrote:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr timon.g...@gmx.ch wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names
for their function parameters.
On 12/29/2011 03:38 AM, bearophile wrote:
Timon Gehr:
On 12/29/2011 02:04 AM, Derek wrote:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehrtimon.g...@gmx.ch wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible
Timon Gehr:
My point is, without named arguments you can improve the names at any
time. With named arguments, you are stuck and have to get it right upfront.
I think library code doesn't change argument names often, and when this happens
I have suggested a way to deprecate argument names.
On 12/29/11 3:46 AM, Timon Gehr wrote:
My point is, without named arguments you can improve the names at any
time. With named arguments, you are stuck and have to get it right upfront.
My point is, without positional arguments you can improve the ordering
at any time. With positional
Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Since some time thanks to a post in this newsgroups I am able to compile DMD,
so I am able to test the changes early. It seems to work in various situations:
import std.stdio,
On Tuesday, 27 December 2011 at 10:57:35 UTC, Peter Alexander
wrote:
On 27/12/11 10:51 AM, deadalnix wrote:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll seem bitter, but I
On 12/27/11 8:19 AM, Alex Rønne Petersen wrote:
Now the only gripe I have left is type inference for lambdas passed as
regular function parameters. Is this something we will see anytime soon?
It's among the [tdpl] bugs, so I hope fairly soon.
Andrei
On 27-12-2011 15:19, Alex Rønne Petersen wrote:
On 27-12-2011 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Awesome!
Now the only gripe I have left is type inference for lambdas passed as
regular
On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei
Alexandrescu wrote:
Imagine how bitter I am that the string lambda syntax didn't
catch on!
Andrei
Please tell me they're not going anywhere. I **really** don't
want to deal
On 27-12-2011 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Awesome!
Now the only gripe I have left is type inference for lambdas passed as
regular function parameters. Is this something we will see
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu
wrote:
Imagine how bitter I am that the string lambda syntax didn't
catch on!
Andrei
Please tell me they're not going anywhere. I **really** don't
want to deal with those being deprecated.
On 12/27/11 9:51 AM, Torarin wrote:
2011/12/27 Joshua Reuschyos...@arkandos.de:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5, 4, 3, 2, 1];
sort!((a, b) = a b)(arr);
}
-
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll seem bitter, but I do not think this changement was really
that important. This is nice, ok, but we have some other really
On 12/27/11 3:35 AM, bearophile wrote:
This program contains wrong syntax because x lacks a type:
void main() {
double delegate(double) f;
f = (x) = x + 1;
}
DMD gives the error messages:
test.d(3): Error: undefined identifier x, did you mean variable f?
test.d(3): Error: cannot
On 12/27/11 4:51 AM, deadalnix wrote:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll seem bitter, but I do not think this changement was really
that important. This is nice,
On 27/12/11 10:51 AM, deadalnix wrote:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll seem bitter, but I do not think this changement was really
that important. This is nice,
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Finally, it's here! I'll be able to use std.algorithm stuff
without tons of named, nested functions now :)
On 12/27/11 9:21 AM, Joshua Reusch wrote:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5, 4, 3, 2, 1];
sort!((a, b) =
On 27-12-2011 11:51, deadalnix wrote:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll seem bitter, but I do not think this changement was really
that important. This is nice,
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message
news:jdckl1$1hfb$1...@digitalmars.com...
Or perhaps even better, when we get fully working UFCS:
auto ints = [0, 1, 2, 3, 4, 5].filter(x = x % 2 != 0);
That is just beautiful.
2011/12/27 Joshua Reusch yos...@arkandos.de:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5, 4, 3, 2, 1];
Wouldn't it be great if Santa were to give us named arguments this year too? :)
1 - 100 of 120 matches
Mail list logo
