At times, like when trying to write a syntactically sweet tuple unpacker, I've
wanted to be able to declare a variable that will be passed by reference to a
function inside the function call. For example:
void doStuff(out uint num) { // Could also be ref uint num.
num = 666;
}
import std.st
On Tue, 31 Mar 2009 06:46:32 +0400, dsimcha wrote:
At times, like when trying to write a syntactically sweet tuple
unpacker, I've
wanted to be able to declare a variable that will be passed by reference
to a
function inside the function call. For example:
void doStuff(out uint num) { //
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> On Tue, 31 Mar 2009 06:46:32 +0400, dsimcha wrote:
> > At times, like when trying to write a syntactically sweet tuple
> > unpacker, I've
> > wanted to be able to declare a variable that will be passed by reference
> > to a
> > function
dsimcha wrote:
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
That said, I don't think there is a need for something like this.
Certainly no speedup and little clarity compared to declaring variable
right before invoking doStuff.
Here's an example of where it would be a useful pi
2009/3/30 dsimcha :
> // How it works now:
> uint foo;
> string bar;
> unpack(foo, bar) = someFunction();
>
> // vs. how I want it to work:
> unpack(auto foo, auto bar) = someFunction();
Cute, but uh, I'd much rather see tuples just be returnable. That
would practically remove the need for out pa
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> 2009/3/30 dsimcha :
> > // How it works now:
> > uint foo;
> > string bar;
> > unpack(foo, bar) = someFunction();
> >
> > // vs. how I want it to work:
> > unpack(auto foo, auto bar) = someFunction();
> Cute, but uh, I'd
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
uint foo;
string bar;
unpack(foo, bar) = someFunction();
// vs. how I want it to work:
unpack(auto foo, auto bar) = someFunction();
Cute, but uh, I'd much rather see tuples just be returnable.
They are.
Andrei
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
> Jarrett Billingsley wrote:
>>
>> 2009/3/30 dsimcha :
>>>
>>> // How it works now:
>>> uint foo;
>>> string bar;
>>> unpack(foo, bar) = someFunction();
>>>
>>> // vs. how I want it to work:
>>> unpack(auto foo, auto bar) = someFunction()
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
uint foo;
string bar;
unpack(foo, bar) = someFunction();
// vs. how I want it to work:
unpack(auto foo, auto bar) = someFunction();
Cute
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
>
> import std.typecons;
>
> Tuple!(int, float) foo()
> {
> return tuple(2, 4.5);
> }
>
> The addition of the alias this feature and of constructor templates makes
> std.typecons.Tuple even better.
>
Cool, but..
Why not just make tup
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
> Jarrett Billingsley wrote:
>> On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
>> wrote:
>>> Jarrett Billingsley wrote:
2009/3/30 dsimcha :
> // How it works now:
> uint foo;
> string bar;
> unpack(foo, bar) =
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
>
> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>
> > Jarrett Billingsley wrote:
> >> On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
> >> wrote:
> >>> Jarrett Billingsley wrote:
> 2009/3/30 dsimcha :
> > // How it
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates makes
std.typecons.Tuple even better.
Cool, but..
Why not j
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
u
Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates
makes
std.typecons.Tuple even bet
On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
>> wrote:
>>>
>>> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>>>
Jarrett Billingsley wrote:
>
> On Tue, Mar 31, 2009 at 1:32 PM, Andrei
On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
>> wrote:
>>>
>>> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>>>
Jarrett Billingsley wrote:
>
> On Tue, Mar 31, 2009 at 1:32 PM, Andrei
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>
>> Jarrett Billingsley wrote:
>>> On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
>>> wrote:
Jarrett Billingsley wrote:
> 2009/3/30 dsimcha :
>> // How it works n
Andrei Alexandrescu wrote:
> Jarrett Billingsley wrote:
>> On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
>> wrote:
>>> import std.typecons;
>>>
>>> Tuple!(int, float) foo()
>>> {
>>>return tuple(2, 4.5);
>>> }
>>>
>>> The addition of the alias this feature and of constructor templates
Bill Baxter, el 1 de abril a las 05:22 me escribiste:
> Right. In my ideal world I could use tuples like this:
>
> (int,float) a;
>
> a = returns_tuple();
>
> a[0] = 2;
> a[1] = 3.4;
>
> (int,float) z = returns_tuple();
>
> (int x, float y) = returns_tuple();
>
> auto tup = (2, 3.4);
>
> t
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
u
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates
makes
std.type
Leandro Lucarella wrote:
Bill Baxter, el 1 de abril a las 05:22 me escribiste:
Right. In my ideal world I could use tuples like this:
(int,float) a;
a = returns_tuple();
a[0] = 2;
a[1] = 3.4;
(int,float) z = returns_tuple();
(int x, float y) = returns_tuple();
auto tup = (2, 3.4);
takes
Tue, 31 Mar 2009 17:54:30 -0700, Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
>> wrote:
>>> Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
wrote:
> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote
Andrei Alexandrescu, el 31 de marzo a las 17:57 me escribiste:
> Leandro Lucarella wrote:
> >Bill Baxter, el 1 de abril a las 05:22 me escribiste:
> >>Right. In my ideal world I could use tuples like this:
> >>
> >>(int,float) a;
> >>
> >>a = returns_tuple();
> >>
> >>a[0] = 2;
> >>a[1] = 3.4;
>
Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the comma expression from
an assignment expression which otherwise would become a part of c
Leandro Lucarella wrote:
Andrei Alexandrescu, el 31 de marzo a las 17:55 me escribiste:
But in Python or ML, no question. I'd happily write a function that
returns (2, 4.2) without giving it much thought. Now perhaps cogent
arguments like "blech" and "belch" can convince me that I should
embrac
Andrei Alexandrescu, el 31 de marzo a las 17:55 me escribiste:
> >But in Python or ML, no question. I'd happily write a function that
> >returns (2, 4.2) without giving it much thought. Now perhaps cogent
> >arguments like "blech" and "belch" can convince me that I should
> >embrace the Tuple!(int
Andrei Alexandrescu:
> Well I think a language can only have so many built-in types. We can't
> go on forever.
Too many built-ins become confusing (see Fortress), but D is quite far from
that point (see Python, that has more than D and they are just fine and easy to
use and remember. I'd also
Leandro Lucarella wrote:
Andrei Alexandrescu, el 31 de marzo a las 17:57 me escribiste:
Agree. They should be first class citizen as dynamic arrays or hashes.
Why? Not grokking it.
It's perfectly explained in this thread why, all I have to say will
repeate something already said (the int[] vs
bearophile wrote:
Andrei Alexandrescu:
Well I think a language can only have so many built-in types. We
can't go on forever.
Too many built-ins become confusing (see Fortress), but D is quite
far from that point (see Python, that has more than D and they are
just fine and easy to use and reme
Sergey Gromov wrote:
Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the com
Sergey Gromov wrote:
Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the com
On Wed, Apr 1, 2009 at 9:55 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
>> wrote:
>>>
>>> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>>>
Jarrett Billingsley wrote:
>
> On Tue, Mar 31, 2009 at 1:32 PM, Andrei
Andrei Alexandrescu, el 31 de marzo a las 18:42 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 31 de marzo a las 17:55 me escribiste:
> >>>But in Python or ML, no question. I'd happily write a function that
> >>>returns (2, 4.2) without giving it much thought. Now perhaps cog
Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Comma expression is not ambiguous. It's a comma expression. Renaming
>> it into a tuple constructor expression does not add any ambiguity.
>> Parentheses here are only required to separate the comma expression
Tue, 31 Mar 2009 18:55:10 -0700, Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
>>
>>> Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression doe
== Quote from Bill Baxter (wbax...@gmail.com)'s article
> Ok, then we'll introduce balanced budget amendment for types to ensure
> this doesn't happen. For every new type added one must be removed.
> We're going to vote complex types off the island, right? Maybe we
> could get rid of associative
On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
wrote:
> I guess I can't bring myself to dislike tuple(1, 2) in D.
>
I'd actually be a heck of a lot happier with that than Tuple!(1,2).
Especially if using it didn't require any explicit import.
--bb
== Quote from Bill Baxter (wbax...@gmail.com)'s article
> On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
> wrote:
> > I guess I can't bring myself to dislike tuple(1, 2) in D.
> >
> I'd actually be a heck of a lot happier with that than Tuple!(1,2).
> Especially if using it didn't require an
Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>>
>> Andrei Alexandrescu wrote:
>>> Jarrett Billingsley wrote:
...
Why not just make tuples first-class types? <_<
>>> Why not not?
>>>
>>> Andrei
>>
>> Because people keep having to invent hacks to work around the fact that
>> we can
On Wed, Apr 1, 2009 at 11:15 AM, dsimcha wrote:
> == Quote from Bill Baxter (wbax...@gmail.com)'s article
>> We're going to vote complex types off the island, right? Maybe we
>> could get rid of associative arrays as a built-in too.
>
> Aren't builtin complex types on the way out anyhow?
Right.
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
wrote:
I guess I can't bring myself to dislike tuple(1, 2) in D.
I'd actually be a heck of a lot happier with that than Tuple!(1,2).
Especially if using it didn't require any explicit import.
--bb
Tuple!(...) tuple(.
Bill Baxter wrote:
Ok, then we'll introduce balanced budget amendment for types to ensure
this doesn't happen. For every new type added one must be removed.
We're going to vote complex types off the island, right? Maybe we
could get rid of associative arrays as a built-in too.
Ironic as that
On Wed, Apr 1, 2009 at 1:12 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
>> wrote:
>>
>>> I guess I can't bring myself to dislike tuple(1, 2) in D.
>>>
>>
>> I'd actually be a heck of a lot happier with that than Tuple!(1,2).
>> Es
Andrei Alexandrescu:
> So we must add lists too.
Notice the the python "list" is an array dynamic on the right, it's not a
linked list.
Regarding tuple: I don't like the name "tuple" of typecons, because they aren't
the tuples of D, they are structs. That's why I have named them Record/record
bearophile wrote:
Andrei Alexandrescu:
So we must add lists too.
Notice the the python "list" is an array dynamic on the right, it's
not a linked list.
I know. My point was that I might want to add a reasonable data
structure to the language, and it's hard to build an argument on what to
Andrei Alexandrescu:
>D is at fault because it called typelists tuples. I told Walter not to, and he
>went ahead and did so anyway. Now we're living with the consequences.<
I see, and you are right. Then why not rename tuples of D2 to a more correct
name (typelists)? Being D2 in alpha still the
On Tue, 31 Mar 2009 23:07:46 -0700, Andrei Alexandrescu
wrote:
>bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> So we must add lists too.
>>
>> Notice the the python "list" is an array dynamic on the right, it's
>> not a linked list.
>
>I know. My point was that I might want to add a reasonabl
Sergey Gromov, el 1 de abril a las 06:08 me escribiste:
> I'm putting together a blog post about a possible design of first-class
> tuples in D. Hope it won't take too long.
> >>> What does "first-class" mean?
> >>
> >> First-class values, like, native, with built-in compiler support.
Andrei Alexandrescu, el 31 de marzo a las 18:50 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 31 de marzo a las 17:57 me escribiste:
> >>>Agree. They should be first class citizen as dynamic arrays or hashes.
> >>Why? Not grokking it.
> >It's perfectly explained in this threa
52 matches
Mail list logo
