Maybe something like this can be added to Fobos:

template Iota(int start, int stop, int step = 1){
    template tuple(T...){
        alias tuple = T;
    }
    static if(start < stop)
        alias Iota = tuple!(start, Iota!(start + step, stop, step));
    else
        alias Iota = tuple!();
}

On Wed, Jan 21, 2015 at 07:14:09PM +0100, zeljkog via Digitalmars-d wrote:
> 
> Maybe something like this can be added to Fobos:
> 
> template Iota(int start, int stop, int step = 1){
>     template tuple(T...){
>         alias tuple = T;
>     }
>     static if(start < stop)
>         alias Iota = tuple!(start, Iota!(start + step, stop, step));
>     else
>         alias Iota = tuple!();
> }

This is actually already implemented as std.typecons.staticIota, but it's currently undocumented and restricted to only Phobos code. I'm not sure why it was decided not to make it public, but if you file an enhancement request, the devs can look at it and decide if it's worth making it public.


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.

On 21.01.15 19:23, H. S. Teoh via Digitalmars-d wrote:
>
> This is actually already implemented as std.typecons.staticIota, but
> it's currently undocumented and restricted to only Phobos code. I'm not
> sure why it was decided not to make it public, but if you file an
> enhancement request, the devs can look at it and decide if it's worth
> making it public.
>

I see, thx.

And good name staticIota, unlike TypeTuple. I always wonder what is raw tuple, TypeTuple or Tuple :)

On 21/01/2015 19:15, zeljkog wrote:
> And good name staticIota, unlike TypeTuple. I always wonder what is raw
> tuple, TypeTuple or Tuple :)

Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a pull to do that (which goes further than the DIP), but I don't know if the deprecation/disruption will be acceptable. If not, perhaps we could just add a better named alias for TypeTuple (e.g. MetaTuple) but keep the same module name. I don't think the status quo is really acceptable.

(In fact, I don't agree with removing deprecated symbols unless they are actually buggy - this is what GTK does. If we kept them there would be less friction and less cause not to deprecate things which are problematic).

On Thursday, 22 January 2015 at 13:06:26 UTC, Nick Treleaven wrote:
> On 21/01/2015 19:15, zeljkog wrote:
>> And good name staticIota, unlike TypeTuple. I always wonder what is raw
>> tuple, TypeTuple or Tuple :)
>
> Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a pull to do that (which goes further than the DIP), but I don't know if the deprecation/disruption will be acceptable. If not, perhaps we could just add a better named alias for TypeTuple (e.g. MetaTuple) but keep the same module name. I don't think the status quo is really acceptable.
>
> (In fact, I don't agree with removing deprecated symbols unless they are actually buggy - this is what GTK does. If we kept them there would be less friction and less cause not to deprecate things which are problematic).

Ah, great, now I am least sure that you and ntrel are the same person :) Fate of your pull and DIP in general is in Andrei hands - but, as he has mentioned in this thread, his mailbox queue is not easy to deal with. So right now can't really do anything but sit and wait.

On 22.01.15 14:06, Nick Treleaven wrote:
> On 21/01/2015 19:15, zeljkog wrote:
>> And good name staticIota, unlike TypeTuple. I always wonder what is raw
>> tuple, TypeTuple or Tuple :)
>
> Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a
> pull to do that (which goes further than the DIP), but I don't know if
> the deprecation/disruption will be acceptable. If not, perhaps we could
> just add a better named alias for TypeTuple (e.g. MetaTuple) but keep
> the same module name. I don't think the status quo is really acceptable.
>

Maybe RawTuple or CtTuple?
Descriptive and As Short As Possible :)

On 1/22/15 5:08 AM, Dicebot wrote:
> On Thursday, 22 January 2015 at 13:06:26 UTC, Nick Treleaven wrote:
>> On 21/01/2015 19:15, zeljkog wrote:
>>> And good name staticIota, unlike TypeTuple. I always wonder what is raw
>>> tuple, TypeTuple or Tuple :)
>>
>> Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a
>> pull to do that (which goes further than the DIP), but I don't know if
>> the deprecation/disruption will be acceptable. If not, perhaps we
>> could just add a better named alias for TypeTuple (e.g. MetaTuple) but
>> keep the same module name. I don't think the status quo is really
>> acceptable.
>>
>> (In fact, I don't agree with removing deprecated symbols unless they
>> are actually buggy - this is what GTK does. If we kept them there
>> would be less friction and less cause not to deprecate things which
>> are problematic).
>
> Ah, great, now I am least sure that you and ntrel are the same person :)
> Fate of your pull and DIP in general is in Andrei hands - but, as he has
> mentioned in this thread, his mailbox queue is not easy to deal with. So
> right now can't really do anything but sit and wait.

I'm ambivalent about this; I think it could go either way without making a huge impact. (BTW I like GTK's idea to keep the old names around. They could be marginalized in the documentation but still allow older programs to build.)

I'm more worried about another trend though (only loosely related to this particular one). I might talk about that tonight.ñ

While working on the new site menus I was copying std modules by hand - and boy, there's just so much work to be done. Streams, json, encoding, mmfile, outbuffer, signals, socket, socketstream, xml, zip - all that stuff, maybe a third of the standard library packages, are /known/ to be in need of a good revamp (ranging from better documenting to refactoring to improving to completely rewriting) yet recently a lot of work has been spent on renaming, splitting, ... - shuffling the rubble in the garden, especially parts that are already good: container, algorithm, range, typecons.

Moreover, there's a ton of brand new work to be done! We don't have standard decent wrappers for libevent or libarchive, networking protocols, web servers, databases, and just a ton of other things.

I hypothesize much of it is because a small improvement to something that's already good is easier to push past review; what's there works, the new stuff is even nicer - game, set, and match. Pull merged. In contrast, embarking on a significant new work is likely to receive a lot more scrutiny and criticism.

This might be because an asymmetry: we have a high bar for reviews and a good process in place, but no strong enough large submissions to make it past it. As a consequence our current dynamics "optimizes" for small improvements of already working code.

In WWI, the advent of mounted machine guns created a large asymmetry between defense and offense: defense was much more effective than offense, which led to the trench stalemate. It seems to me we have an asymmetry between the review process and the strength of potential submissions. The WWI stalemate was broken by the invention of the tank. We apparently need an equivalent of it :o).

===

Take a look at https://github.com/D-Programming-Language/phobos/pull/2687/files. So we have a bunch of replacements like "TypeTuple" to "meta.List" and "allSatisfy" to "meta.all". Are the new names nicer? Arguably. I like them! Do they improve things? I guess. There'd be less confusion about TypeTuple not always containing types etc, which does matter. Will they have an important contribution to the adoption of D? Very, very little if at all, especially compared with the opportunity costs: all the good work that WASN'T done by the talented contributors involved while they were busy renaming things.

That said https://github.com/D-Programming-Language/phobos/pull/2687 will probably get pulled. Why? Because it's sensible, and because it's there. It's the sensible, okay work that I'm most worried about, even more than bad work.

Bad work is visibly undesirable so it won't get far. The problem with okay work is it does get implemented and pulled, so it takes away time from the great work that does make a difference.


Andrei

Things like std.typetuple, while not being as broken as std.json implementation-wise, deal good amount of damage being a technical debt. It simply unpleasant to build anything on top of it and Phobos lacks quite many metaprogramming utilities. It is also a small but important step in simplifying related learning curve.

I agree it shouldn't be considered a priority but if there is a work done already there - why not?

On 1/22/15 2:39 PM, Dicebot wrote:
> Things like std.typetuple, while not being as broken as std.json
> implementation-wise, deal good amount of damage being a technical debt.
> It simply unpleasant to build anything on top of it and Phobos lacks
> quite many metaprogramming utilities. It is also a small but important
> step in simplifying related learning curve.
>
> I agree it shouldn't be considered a priority but if there is a work
> done already there - why not?

I agree! And... I was afraid you were going to say all that. -- Andrei

On Thu, Jan 22, 2015 at 01:21:39PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> I'm ambivalent about this; I think it could go either way without making a huge impact. (BTW I like GTK's idea to keep the old names around. They could be marginalized in the documentation but still allow older programs to build.)

+1. I think we should adopt this policy. Deprecated symbols should stick around basically forever (possibly relegated to a dedicated submodule publicly imported by the original module, if we don't like accumulating cruft in the latter), unless they were deprecated because we wanted to reuse the symbol for something else. So they should basically have no more documentation after the deprecation cycle but they should still carry the deprecated() tag to point old code to the right place.


[...]
> That said https://github.com/D-Programming-Language/phobos/pull/2687 will probably get pulled. Why? Because it's sensible, and because it's there.  It's the sensible, okay work that I'm most worried about, even more than bad work.

Yay! Does that mean we can merge 2687? :-P


T

-- 
Жил-был король когда-то, при нём блоха жила.