Hi,
with the new beta I get the warning I should use
std.algorithm.sort instead the .sort property. I thought the
std.algorithm.sort method is used in this example?
void main()
{
import std.algorithm: sort, uniq, map;
import std.array: array;
string[]
On Tuesday, 10 March 2015 at 17:42:37 UTC, Ali Çehreli wrote:
You are right again. :) However, putting the lazy-taking
function outside the whole expression makes it visible right
away, making easy for me to realize that the execution order
may be different from common chains.
lazy aka named
to use the built-in sort property. You need to
use parens if you want to use the function in std.algorithm with an array
and UFCS, e.g.
arr.sort();
- Jonathan M Davis
I just became aware of
http://dlang.org/phobos/std_exception.html#.ifThrown . It's neat,
but it seems non-obvious to me how lazy + UFCS should work in
general.
consider
void lazily(T)(lazy T expression)
{
expression();
}
It's clear when saying lazily(a.b().c()); that the whole of
a.b
On 03/09/2015 03:03 PM, Logan Capaldo wrote:
I just became aware of
http://dlang.org/phobos/std_exception.html#.ifThrown . It's neat, but it
seems non-obvious to me how lazy + UFCS should work in general.
consider
void lazily(T)(lazy T expression)
{
expression();
}
It's clear when saying
Is this a normal behaviour ?
---
void main()
{
import std.algorithm;
auto list = [0,1,2,3];
alias poly = map;
list.poly!(a = a + a);
}
---
outputs:
Error: no property 'poly' for type 'int[]'
Baz:
Is this a normal behaviour ?
Try to move the definition of poly to module-level scope.
This is a design decision to avoid other troubles.
Bye,
bearophile
On Friday, 26 December 2014 at 15:58:18 UTC, aldanor wrote:
Please ignore the missing new keywords in the code and other
minor typos :)
Any opinions please?.. Would be much appreciated.
Thanks!
On Sat, 27 Dec 2014 23:34:06 +
aldanor via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Friday, 26 December 2014 at 15:58:18 UTC, aldanor wrote:
Please ignore the missing new keywords in the code and other
minor typos :)
Any opinions please?.. Would be much
) { super(id); } // -- package
public this(...) { // high-level public ctor }
Group group() const {
int group_id = get_group(this.id);
return Group(group_id);
}
}
--
Solution 2: use UFCS and swap the group() / dataset(name)
functions between
Please ignore the missing new keywords in the code and other
minor typos :)
I can't understand how to use UFCS with instance of class:
void main()
{
string name = Suliman;
userName username = new userName(name);
/// How to use UFCS here?
userName.name.sayHello();
///
}
class userName
{
string name;
this(string name)
{
this.name = name
On Mon, 10 Nov 2014 19:07:38 +
Suliman via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
/// How to use UFCS here?
userName.name.sayHello();
///
you can't.
a little explanation: UFCS substitutes only the first argument. and for
class methods first argument is hidden
On Mon, 10 Nov 2014 19:07:38 +, Suliman wrote:
I can't understand how to use UFCS with instance of class:
void main()
{
string name = Suliman;
userName username = new userName(name);
/// How to use UFCS here?
userName.name.sayHello();
///
}
class userName {
string name
On 11/10/2014 11:07 AM, Suliman wrote:
I can't understand how to use UFCS with instance of class:
void main()
{
string name = Suliman;
userName username = new userName(name);
/// How to use UFCS here?
userName.name.sayHello();
///
}
class userName
{
string name;
this(string name
Thanks!
Ali Çehreli, could you add this mention and possible the example
to your book?
On 11/10/2014 12:04 PM, Suliman wrote:
Thanks!
Ali Çehreli, could you add this mention and possible the example to your
book?
Of course. Perhaps I should rephrase some of the descriptions here?
http://ddili.org/ders/d.en/ufcs.html
Please email me at acehr...@yahoo.com if you have specific
On Sunday, 28 September 2014 at 20:28:11 UTC, Jay wrote:
fwiw here's what i wrote:
template New(T) if (is(T == class)) {
T New(Args...) (Args args) {
return new T(args);
}
}
My try
template New(T) if (is(T == class))
{
T New(Args...) (Args args) {
return new
On 09/30/2014 10:35 AM, Nordlöw wrote:
On Sunday, 28 September 2014 at 20:28:11 UTC, Jay wrote:
fwiw here's what i wrote:
template New(T) if (is(T == class)) {
T New(Args...) (Args args) {
return new T(args);
}
}
My try
template New(T) if (is(T == class))
{
T
On 09/30/2014 11:07 AM, Ali Çehreli wrote:
To make a nested class unnested, declare it as static, which seems to
work in your case as well:
class C { int x, y; }
auto x = New!C();
Copy+paste cannot read my mind. :( Of course there should be 'static'
keyword there. :p
On 9/30/14 2:07 PM, Ali Çehreli wrote:
Apparently, a class definition even inside a unittest blocks are
considered to be nested classes.
Normally, objects of nested classes are created by the 'this.new'
syntax, 'this' meaning the object that wraps the nested class.
I think unit test blocks
On Sunday, 28 September 2014 at 22:17:03 UTC, Meta wrote:
I'm not sure. Maybe it's on the same level as the Lambda
Abstraction (14.5), but you'll probably have to do some testing
to figure it out exactly.
precedence levels seem to be defined in `src/parse.h` (the `PREC`
enum) and assigned to
i want to chain 'new' with method calls on the created object. i
found this on the internet:
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF);
it would look much nicer with UFCS:
window.mainWidget = Button.new().text(Hello
worldd).textColor(0xFF);
well, it's
On Sunday, 28 September 2014 at 19:11:23 UTC, Jay wrote:
i want to chain 'new' with method calls on the created object.
i found this on the internet:
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF);
it would look much nicer with UFCS:
window.mainWidget
thanks! but i'm still interested *why* you can't have this with
'new'. if there's no good reason i will file a bug report.
On Sunday, 28 September 2014 at 19:19:56 UTC, Foo wrote:
mixin template New(T) if (is(T == class)) {
static T New(Args...)(Args args) {
return new
On Sunday, 28 September 2014 at 19:32:11 UTC, Jay wrote:
thanks! but i'm still interested *why* you can't have this with
'new'. if there's no good reason i will file a bug report.
Because `new` is not a function - it's an operator.
On Sunday, 28 September 2014 at 19:41:29 UTC, Idan Arye wrote:
Because `new` is not a function - it's an operator.
do you think the function call syntax has any chance to be
implemented? is it just me who needs it?
On Sunday, 28 September 2014 at 19:19:56 UTC, Foo wrote:
mixin template New(T) if (is(T == class)) {
static T New(Args...)(Args args) {
return new T(args);
}
}
fwiw here's what i wrote:
template New(T) if (is(T == class)) {
T New(Args...) (Args args) {
On Sunday, 28 September 2014 at 19:11:23 UTC, Jay wrote:
i want to chain 'new' with method calls on the created object.
i found this on the internet:
window.mainWidget = (new Button()).text(Hello
worldd).textColor(0xFF);
it would look much nicer with UFCS:
window.mainWidget
On Sunday, 28 September 2014 at 20:30:42 UTC, Meta wrote:
class Button
{
typeof(this) text(string t)
{
return this;
}
typeof(this) textColour(int c)
{
return this;
}
}
void main()
{
auto b = new
On Sunday, 28 September 2014 at 20:50:07 UTC, Jay wrote:
On Sunday, 28 September 2014 at 20:30:42 UTC, Meta wrote:
class Button
{
typeof(this) text(string t)
{
return this;
}
typeof(this) textColour(int c)
{
return
On Tuesday, 9 September 2014 at 18:46:31 UTC, ketmar via
Digitalmars-d-learn wrote:
UFCS is not working for nested functions. this is not a bug, it
was
designed this way. the same for 'with', i believe.
Apparently it is a bug that UFCS doesn't work with 'with'
statement.
https
On Wed, 10 Sep 2014 13:58:18 +
Danyal Zia via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Apparently it is a bug that UFCS doesn't work with 'with'
statement.
my fault, i thought that it shouldn't. i'm still not Guru. too bad,
will work. ;-)
signature.asc
Description
Hi,
I don't know if this has been mentioned before, but I found two
strange cases where UFCS doesn't work.
Case # 1: When the functions for UFCS are defined inside main
scope
class Rect {
int x = 20;
int y = 20;
}
void main() {
import std.stdio : writeln;
int area
On Tue, 09 Sep 2014 17:58:14 +
Danyal Zia via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Case # 1: When the functions for UFCS are defined inside main
scope
UFCS is not working for nested functions. this is not a bug, it was
designed this way. the same for 'with', i
On Tuesday, 9 September 2014 at 17:58:16 UTC, Danyal Zia wrote:
As far as I know, UFCS are designed to make it easy to extend
the class for specific applications, however, without the
ability to use UFCS for those cases, it limits its usefulness.
Are these oversights/bugs? Or is their any
Puming:
is this a good practice to use `ref in` with structs instead of
traditional pointer syntax (which does not play well with UFCS
though) ? Is there any perfomance implications with `ref in`? I
tried that it does not seem to copy the parameter value,
A ref is equivalent to a pointer
On Tuesday, 1 July 2014 at 07:53:27 UTC, bearophile wrote:
Puming:
is this a good practice to use `ref in` with structs instead
of traditional pointer syntax (which does not play well with
UFCS though) ? Is there any perfomance implications with `ref
in`? I tried that it does not seem
On 07/01/2014 03:21 AM, Puming wrote:
I can safely assume ref is better than pointer here
I agree.
because it plays nicely with UFCS.
I don't understand that part. :) The following is the same program with
just two differences: prompt() takes a pointer and 'server' is a pointer.
import
On Tuesday, 1 July 2014 at 13:53:12 UTC, Ali Çehreli wrote:
On 07/01/2014 03:21 AM, Puming wrote:
I can safely assume ref is better than pointer here
I agree.
because it plays nicely with UFCS.
I don't understand that part. :) The following is the same
program with just two differences
:
```d
string p = server.prompt;
```
is this the correct way to use struct and UFCS? it does not seem
to copy there.
~ @ ~ server.ip ~ : ~ server.port;
}
```
should be `server.port.to!int`;
and call it with UFSC:
```d
string p = server.prompt;
```
is this the correct way to use struct and UFCS? it does not
seem to copy there.
(ref in Server server)
{
return server.user ~ @ ~ server.ip ~ : ~ server.port;
}
```
should be `server.port.to!int`;
I think it should actually be server.port.to!string;
is this the correct way to use struct and UFCS? it does not seem to
copy there.
I don't understand your question but I
user;
}
```
extension method here:
```d
string prompt(ref in Server server)
{
return server.user ~ @ ~ server.ip ~ : ~ server.port;
}
```
should be `server.port.to!int`;
I think it should actually be server.port.to!string;
is this the correct way to use struct and UFCS? it does
qznc:
Operator precedence of . is higher than unary minus.
You are right, I didn't know it, so Typedef and constructors are
not to blame:
double foo(in double x) {
assert (x = 0);
return x;
}
void main() {
assert(-1.foo == -1);
}
Is this a good design of the operator
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a1 = Foo(1);
pragma(msg, typeof(a1));
auto a2 = 1.Foo;
pragma(msg, typeof(a2));
auto a3 = Foo(-1);
pragma(msg, typeof(a3));
auto a4 = -1.Foo;
pragma(msg, typeof(a4));
}
It prints:
On Wednesday, 6 November 2013 at 11:04:05 UTC, bearophile wrote:
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a1 = Foo(1);
pragma(msg, typeof(a1));
auto a2 = 1.Foo;
pragma(msg, typeof(a2));
auto a3 = Foo(-1);
pragma(msg, typeof(a3));
qznc:
Operator precedence of . is higher than unary minus.
Is this good?
However, what is Typedef for?
It's to create a differently named type, useful for stronger
static typing, to increase code clarity and avoid some bugs.
If you have a function like this:
double foo(in double x,
On 11/06/2013 03:04 AM, bearophile wrote:
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
auto a1 = Foo(1);
pragma(msg, typeof(a1));
auto a2 = 1.Foo;
pragma(msg, typeof(a2));
auto a3 = Foo(-1);
pragma(msg, typeof(a3));
auto a4 = -1.Foo;
On Wednesday, 6 November 2013 at 17:10:34 UTC, Ali Çehreli wrote:
I would be very surprised if unary - produced a different
type from the operand:
Ali
Operator does not produce type, it produces value of expression,
and type of expression happens not to be the type you expected.
But such
On 11/06/2013 09:46 AM, Maxim Fomin wrote:
On Wednesday, 6 November 2013 at 17:10:34 UTC, Ali Çehreli wrote:
I would be very surprised if unary - produced a different type from
the operand:
Ali
Operator does not produce type, it produces value of expression, and
type of expression
On Wednesday, 6 November 2013 at 18:02:32 UTC, Ali Çehreli wrote:
But such
expectations need not correspond to language rules (try to
think from
from language laywer perspective).
I still argue that the expression -expr must have the same type
as expr.
In bearophile case, I guess
On Wednesday, 6 November 2013 at 18:16:04 UTC, Maxim Fomin wrote:
I think that reason for such behavior is the way used defined
operator overloading functions are implemented, not the
language per se, so programmers confuse themselves.
What about other possible reason - Typedef implementation
Dicebot:
Typedef implementation sucks? ;)
So do you suggest to open some enhancement request/bug report on
Typedef?
Bye,
bearophile
On Wednesday, 6 November 2013 at 21:57:47 UTC, bearophile wrote:
Dicebot:
Typedef implementation sucks? ;)
So do you suggest to open some enhancement request/bug report
on Typedef?
Bye,
bearophile
Sure. get enough such reports and we may even get it back as
language feature :) (I think
Check this simple code:
import std.stdio;
import std.conv;
bool is_zero(T)(T i) { return to!int(i) == 0; }
void main() { 0.is_zero.writeln; }
This code print true of course.
If you replace to!int(i) == 0 with i == 0 compiler gives this
error:
Error: no property 'is_zero' for type 'string'
Andrea Fontana:
Shoudn't 0.is_zero give this error too?
Possibly yes. I put this enhancement request in Bugzilla few
months ago, but I don't remember its number now.
Bye,
bearophile
Am Thu, 31 Oct 2013 11:58:18 +0100
schrieb Andrea Fontana nos...@example.com:
Check this simple code:
import std.stdio;
import std.conv;
bool is_zero(T)(T i) { return to!int(i) == 0; }
void main() { 0.is_zero.writeln; }
This code print true of course.
If you replace to!int(i) ==
On 2013-09-09 19:15, H. S. Teoh wrote:
I don't think UFCS works with qualified names right now. This is a known
issue.
As far as I know it's a design decision.
--
/Jacob Carlborg
On Mon, Sep 09, 2013 at 07:07:58PM +0200, Gyron wrote:
Hey there, I've experimented a little with UFCS today and ran into a
problem.
My first question, which is kinda off-topic:
Why does D use the int type if you give it a number started with
0x(hex), shouldn't it use uint for that ?
Good
Hey there, I've experimented a little with UFCS today and ran
into a problem.
My first question, which is kinda off-topic:
Why does D use the int type if you give it a number started with
0x(hex), shouldn't it use uint for that ?
Here comes the real question:
I've extended the int by one
On Monday, 9 September 2013 at 17:17:07 UTC, H. S. Teoh wrote:
On Mon, Sep 09, 2013 at 07:07:58PM +0200, Gyron wrote:
Hey there, I've experimented a little with UFCS today and ran
into a
problem.
My first question, which is kinda off-topic:
Why does D use the int type if you give it a number
On Monday, 9 September 2013 at 17:07:59 UTC, Gyron wrote:
Hey there, I've experimented a little with UFCS today and ran
into a problem.
My first question, which is kinda off-topic:
Why does D use the int type if you give it a number started
with 0x(hex), shouldn't it use uint
On 2013-08-29 22:02, Andrej Mitrovic wrote:
However it does work for local imports (I think this was new in 2.063):
void main()
{
import std.range;
assert([].empty); // ok
}
empty is declared at module scope.
--
/Jacob Carlborg
On Thursday, 29 August 2013 at 21:10:41 UTC, Rory McGuire wrote:
On Thursday, 29 August 2013 at 21:06:04 UTC, Rory McGuire wrote:
Hi all,
I've got this little ctfe template function that checks if a
function called member with first argument T exists. Its for
checking if a type has a custom
On 2013-08-28 23:28, ixid wrote:
UFCS does not work in this template where the normal function call
syntax will work:
template test(alias fun) {
auto test(T)(T n) {
return n.fun;
}
}
Is this the same as the inability to use UFCS with functions declared in
the same scope
On Thursday, 29 August 2013 at 06:23:32 UTC, Jacob Carlborg wrote:
UFCS only works for module level functions.
What is the reason for this limitation?
On 8/29/13, Jacob Carlborg d...@me.com wrote:
UFCS only works for module level functions.
However it does work for local imports (I think this was new in 2.063):
void main()
{
import std.range;
assert([].empty); // ok
}
Hi all,
I've got this little ctfe template function that checks if a
function called member with first argument T exists. Its for
checking if a type has a custom encoder.
bool hasUFCSmember(T, string member)() {
T v;
// would be nice if we could use ParameterTypeTuple to get the
On Thursday, 29 August 2013 at 21:06:04 UTC, Rory McGuire wrote:
Hi all,
I've got this little ctfe template function that checks if a
function called member with first argument T exists. Its for
checking if a type has a custom encoder.
bool hasUFCSmember(T, string member)() {
T v;
UFCS does not work in this template where the normal function
call syntax will work:
template test(alias fun) {
auto test(T)(T n) {
return n.fun;
}
}
Is this the same as the inability to use UFCS with functions
declared in the same scope as the call
Why does UFCS seem to require that functions be defined in a
higher (global being the highest) scope than themselves while the
normal function syntax works fine?
This is OK:
int fun1(int n) {
return n + 1;
}
int fun2(int n) {
return n.fun1;
}
This is also OK:
int fun3(int n
ixid:
This is not OK:
int fun5(int n) {
int fun6(int n) {
return n + 1;
}
return n.fun6;
}
Unfortunately this is by design, and at the moment it's unlikely
to change. And I think it's done this way to avoid troubles with
code in class methods.
Bye,
a template
}
Should the constraint on opDispatch allow the UFCS to call on S?
To avoid this kind of issues:
struct S {
template opDispatch(string s) if (s.startsWith(foo)) {
void opDispatch(T...)(T t) {
writeln(s);
}
}
}
And, yes, the compiler
On Tuesday, 2 July 2013 at 11:04:20 UTC, Artur Skawina wrote:
To avoid this kind of issues:
struct S {
template opDispatch(string s) if (s.startsWith(foo)) {
void opDispatch(T...)(T t) {
writeln(s);
}
}
}
That's a handy workaround,
!(to) isn't
a template
}
Should the constraint on opDispatch allow the UFCS to call on
S?
That's a compiler bug.
http://d.puremagic.com/issues/show_bug.cgi?id=10526
Kenji Hara
on opDispatch allow the UFCS to call on S?
struct S
{
}
void f(S)
{
}
void main()
{
S s;
with (s)
{
f(); // compiler error
}
}
Rather disappointing that this fails. Anyone know if this is an
expected limitation of UFCS or a bug?
--rt
Rob T:
Rather disappointing that this fails. Anyone know if this is an
expected limitation of UFCS or a bug?
Probably no one thought on this case. Why do you think it's
useful?
Bye,
bearophile
On Wednesday, 12 June 2013 at 11:05:22 UTC, bearophile wrote:
Rob T:
Rather disappointing that this fails. Anyone know if this is
an expected limitation of UFCS or a bug?
Probably no one thought on this case. Why do you think it's
useful?
Bye,
bearophile
If we're to use UFCS as a means
On Monday, 10 June 2013 at 08:13:42 UTC, John Colvin wrote:
On Monday, 10 June 2013 at 02:02:09 UTC, Timothee Cour wrote:
UFCS chains are problematic when a symbol is ambiguous (eg
after import
std.stdio:write;import std.file:write);
I previously suggested to add the syntax
'arg1
.
* systematic way to handle the such cases, whereas renamed
local imports
require to 'guess' a good name, eg import std.file:write2=write;
Do you guess identifier names when you introduce other symbols,
too?
* renamed local imports require 1 import declaration syntax per
ambiguous
UFCS
On Tuesday, 11 June 2013 at 18:47:08 UTC, timotheecour wrote:
On Monday, 10 June 2013 at 08:13:42 UTC, John Colvin wrote:
On Monday, 10 June 2013 at 02:02:09 UTC, Timothee Cour wrote:
UFCS chains are problematic when a symbol is ambiguous (eg
after import
std.stdio:write;import std.file:write
On Monday, 10 June 2013 at 02:02:09 UTC, Timothee Cour wrote:
UFCS chains are problematic when a symbol is ambiguous (eg
after import
std.stdio:write;import std.file:write);
I previously suggested to add the syntax
'arg1.(std.file.write)(arg2)'
(see 'support UFCS with fully qualified function
UFCS chains are problematic when a symbol is ambiguous (eg after import
std.stdio:write;import std.file:write);
I previously suggested to add the syntax
'arg1.(std.file.write)(arg2)'
(see 'support UFCS with fully qualified function names (was in
digitalmars.D.learn)' to avoid breaking UFCS
http://dpaste.dzfl.pl/79c29c19
(What you want to do does not work, but the issue is not that
UFCS does not work with opCall. It does.)
Thanks for the insights, undfortunatelly you're right. Is this
behaviour on purpose, or considered a bug ?
Couldn't read that much out of the original
On 06/05/2013 05:11 PM, ParticlePeter wrote:
http://dpaste.dzfl.pl/79c29c19
(What you want to do does not work, but the issue is not that UFCS
does not work with opCall. It does.)
Thanks for the insights, undfortunatelly you're right. Is this behaviour
on purpose, or considered a bug
UFCS is working with opCall already.
The reason your code does not work is that UFCS only works with
module-level symbols (and with the latest release also for
locally imported symbols IIRC.)
What do you mean with locally import symbols, isn't that the
normal import statement ? Could you
On 06/03/2013 06:25 PM, ParticlePeter wrote:
UFCS is working with opCall already.
The reason your code does not work is that UFCS only works with
module-level symbols (and with the latest release also for locally
imported symbols IIRC.)
What do you mean with locally import symbols, isn't
On 06/01/2013 05:22 AM, ParticlePeter wrote:
3. If not 1. Would this be a valid feature requst ?
Looks like this request:
http://d.puremagic.com/issues/show_bug.cgi?id=9857
Ali
Hello,
after watching Walters Talk about Component Programming ( link
Bellow ) I was quite fond of his pipelining approach.
I tried the following and had to realize that this way using UFCS
isn't working ( or I do something wrong ).
// I want to write On Canvas1 | draw Shape1 | draw Shape2
I'd like to be able to use UFCS with fully qualified function names.
A typical use case is to disambiguate , as in the following case:
import std.path;
import std.string;
void main(){
//Error: std.path.join()(const(char)[] p1, const(char)[] p2, const(char[
])[] more...) at ... conflicts
Timothee Cour:
I'd like to be able to use UFCS with fully qualified function
names.
auto a=.(std.path.join)(\n);
It seems an acceptably-looking syntax. But maybe D.learn is not
the best place to discuss new D syntax.
Regarding new UFCS-related syntax, I sometimes wish for:
alias T
Timothee Cour:
auto a=.(std.path.join)(\n);
I suggest to present it in the main D newsgroup. And if people
don't hate it, to later write an enhancement request in bugzilla.
Bye,
bearophile
Timon Gehr:
I think what you call flip2 should be called flip.
Why?
Bye,
bearophile
On Friday, 26 April 2013 at 10:52:09 UTC, bearophile wrote:
Timon Gehr:
I think what you call flip2 should be called flip.
Why?
Bye,
bearophile
flip2 is the more general and useful function with new
functionality so there's no need for what was flip and we should
call the new function
ixid:
flip2 is the more general and useful function with new
functionality so there's no need for what was flip and we
should call the new function 'flip'.
I don't agree. Maybe you are missing something.
I expect a function named flip to do:
flip!foo(a, b, c) === foo(c, b, a)
flip!foo(a,
On 4/26/13 8:59 AM, bearophile wrote:
ixid:
flip2 is the more general and useful function with new functionality
so there's no need for what was flip and we should call the new
function 'flip'.
I don't agree. Maybe you are missing something.
I expect a function named flip to do:
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?
Why flip in the first place?
I don't know, it's the
On 04/26/2013 10: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?
Why flip in the
201 - 300 of 412 matches
Mail list logo
