I wonder if tuple should automatically expand (flatten) into a list of arguments not only when used with template parameters, but with regular functions as well. This so, that it would enable composition of tuple returning functions with functions that take in individual arguments instead of a tuple, enabling that:

Tuple!(int, int) getTuple()
{
    //...
}

void fun(int arg1, int arg2)
{
    //...
}

void main()
{
    fun( getTuple() );
}

On 10/04/2012 05:16 PM, Tommi wrote:
> I wonder if tuple should automatically expand (flatten) into a list of
> arguments not only when used with template parameters, but with regular
> functions as well. This so, that it would enable composition of tuple
> returning functions with functions that take in individual arguments
> instead of a tuple, enabling that:
>
> Tuple!(int, int) getTuple()
> {
>      //...
> }
>
> void fun(int arg1, int arg2)
> {
>      //...
> }
>
> void main()
> {
>      fun( getTuple() );
> }

No, it should not.

void main(){
    fun(getTuple().expand);
}

On 2012-40-04 00:10, Tommi <tommitissari@hotmail.com> wrote:

> (tuples automatically expand if needed)

False. Typetuples do, but those cannot be returned from functions.

-- 
Simen

On 2012-27-04 07:10, Walter Bright <newshound1@digitalmars.com> wrote:

>> * OpCmp returning an int is fugly I r sad
>
> How else would you return a 3 state value?

enum Comparison {
    Before = -1,
    Same = 0,
    After = 1,
    Unordered = NaN,
}

I'm not saying it should be done, but it would be more readable
(and more cmoplex to write).

-- 
Simen

On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:
>
> void main(){
>     fun(getTuple().expand);
> }

Great, that works for me. It would be probably confusing if they tuples expanded automatically; non-obvious if you'd be passing one argument or multiple.

On 2012-10-04, 20:56, Tommi wrote:

> On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:
>>
>> void main(){
>>     fun(getTuple().expand);
>> }
>
> Great, that works for me. It would be probably confusing if they tuples expanded automatically; non-obvious if you'd be passing one argument or multiple.

There's another reason:

void foo(T)(T, int, float);
void foo(T)(string, T);

Tuple!(int, float) getTuple();

foo("Hello", getTuple()); // What to call?

And:

void baz(T...)(T t);

baz(getTuple()) // Expand or not?


And while this is a constructed example, there is also the matter of
exponential possibilities for the overload system (Oh, so that didn't
work, maybe if I expand *this* tuple? No. *That* tuple? ...)

-- 
Simen

On Wednesday, 3 October 2012 at 21:31:52 UTC, DypthroposTheImposter wrote:
>   D is pretty cool, perhaps someday I can use it instead of C++ and have cool shit like fast build times, modules, no more bloody headers, sane templates, CTFE, UFCS etc
>
>  But can the D GC ever be made:
>
> 1. precise
> 2. able to scale to large-ish data set(2gig+)
> 3. No long stalls(anything over a couple millisecond(<3))


This figure is quite meaningless: if I split a collection phase in several 2ms portion, it would be conformat yet the user would still see long stalls: you need to define both a period and a maximum period of time usable by the GC in this period.


> Q. Curious, would it be compacting?


Add VM-aware GC (http://lambda-the-ultimate.org/node/2391) and you'll have also my ideal but non existant GC.

That said I know two free languages with a "real time"  GC: SuperCollider and Nimrod.

>
>  If not then I'm stuck not using it much--
>
> Which leaves me with structs, and lets just say D struct are not impressive--
>
>
> * Oh and on a totally unrelated note, D needs Multiple return values. Lua has it, it's awesome.


Agreed here.

Regards,
renoX

> D doesn't want to be left out does it?
>
> * OpCmp returning an int is fugly I r sad
>
> * why is haskell so much shorter syntax, can D get that nice syntax plssssssssss
>
> STAB!

On 10/3/2012 11:50 PM, Jacob Carlborg wrote:
> On 2012-10-04 01:33, Alex Rønne Petersen wrote:
>
> > Use tuples. Multiple return values (as far as ABI goes) are impractical
> > because every major compiler back end (GCC, LLVM, ...) would have to be
> > adjusted for every architecture.
>
> Why can't it just be syntax sugar for returning a struct?
>

That's really the only credible way. A tuple should be an anonymous struct with the fields being the elements of the tuple.

The main issue for me for having perfect tuples is that the layout of fields in a struct is different from the layout of parameters being passed on the stack to a function. Ideally,

   struct S { int a; int b; }
   void foo(int p, int q);
   S s;
   foo(s);

should work (setting aside for the moment that they are different types). Unfortunately, the variety of function calling ABIs makes this impractical.

So tuples in a language like D that must conform to external ABIs is that tuples will always have some rough edges.

> Ideally,
>    struct S { int a; int b; }
>    void foo(int p, int q);
>    S s;
>    foo(s);
>
> should work (setting aside for the moment that they are different types). Unfortunately, the variety of function calling ABIs makes this impractical.
> So tuples in a language like D that must conform to external ABIs is that tuples will always have some rough edges.

Why not simply introduce an "expand" property for structs?
----
foo(s.expand) //equivalent to foo(s.a,s.b)
----
That would be the exact analogous of expand for tuples and would maintain a sane type system .

On 2012-10-05 04:57, timotheecour wrote:

> Why not simply introduce an "expand" property for structs?
> ----
> foo(s.expand) //equivalent to foo(s.a,s.b)
> ----
> That would be the exact analogous of expand for tuples and would
> maintain a sane type system .

We already have the .tupleof property:

struct Foo
{
    int x;
    int y;
}

void foo (int a, int b)
{
    writeln(a, " ", b);
}

void main ()
{
    auto f = Foo(1, 2);
    foo(f.tupleof);
}

This works today and I'm pretty sure it has for a long time.

-- 
/Jacob Carlborg