On Wednesday, 21 January 2015 at 18:26:11 UTC, H. S. Teoh via Digitalmars-d wrote:
> 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

There was a PR to make `staticIota` public, but it was superceded by a more general `toTypeTuple`[1] that works with any CTFE-able range, including the titular `iota`. It too was eventually closed, this time because of the whole naming situation. It's an unfortunate situation, but now that we've come this far, I think the way forward is to go ahead and try to get the std.meta rename merged.

[1] https://github.com/D-Programming-Language/phobos/pull/1472

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.

I'm excited for that DIP to be implemented so I'll have my own Phobos module.

On Friday, 23 January 2015 at 00:52:33 UTC, Andrei Alexandrescu wrote:
> 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

Sorry, I don't understand what I have done wrong this time :)

So, to put it clear : do you approve merging https://github.com/D-Programming-Language/phobos/pull/2687 in general? (without any details about actual std.meta module layout etc). Assuming that old std.typetuple will be kept deprecated and (eventually) hidden from docs without removal for a very long time of course.

On 1/23/15 7:21 AM, Dicebot wrote:
> So, to put it clear : do you approve merging
> https://github.com/D-Programming-Language/phobos/pull/2687 in general?
> (without any details about actual std.meta module layout etc). Assuming
> that old std.typetuple will be kept deprecated and (eventually) hidden
> from docs without removal for a very long time of course.

I made a pass through the entire document and discussion and it seems to need a few improvements before being pulled.

The main issues I see are (a) the names changed from a confusing word to a confusing idiom; (b) the Pack template, probably the one thing that could add value to the establishment, is private.

So in the bad old times we had this confusing name Typelist in std.typelist and some okay/meh names like staticMap and staticIndexOf.

With the new coolness std.typelist.Typelist is std.meta.list.List. That is confusing if used standalone as "List" after importing "std.meta.list" and a good mouthful to use with full qualification, so the following idiom is proposed:

import meta = std.meta.list;

This doesn't sound good. If one is in the need for some list-specific stuff, how come they have to import std.meta.list and then call it meta? Does one ever use import container = std.container.array?

Also there's only std.meta.list and no other std.meta.xxx. Is there a plan there?

Why not use packages etc? Just define TemplateList and TemplatePack in std.meta and call it a day.


Andrei

Thanks, I have copied your comments to PR to keep it all in one place.

On 01/22/2015 10:21 PM, Andrei Alexandrescu wrote:
> 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.

Leave the better part of this to freestanding libraries, they prosper much better.

14 database drivers
http://code.dlang.org/?sort=updated&category=library.database
24 networking libraries
http://code.dlang.org/?sort=updated&category=library.network
5 JSON libraries
http://code.dlang.org/search?q=json

A lot of them are quite good and it has become really simple to write a nice library that is well tested and documented.
I try to maintain this library as state-of-the-art D project
with dub, ddox, travis-ci and doveralls integration.

https://github.com/MartinNowak/bloom

On 1/30/15 5:41 AM, Martin Nowak wrote:
>
> Leave the better part of this to freestanding libraries, they prosper
> much better.
>
> 14 database drivers
> http://code.dlang.org/?sort=updated&category=library.database
> 24 networking libraries
> http://code.dlang.org/?sort=updated&category=library.network
> 5 JSON libraries
> http://code.dlang.org/search?q=json
>
> A lot of them are quite good and it has become really simple to write a
> nice library that is well tested and documented.
> I try to maintain this library as state-of-the-art D project
> with dub, ddox, travis-ci and doveralls integration.
>
> https://github.com/MartinNowak/bloom

I think we need to promote the best of the breed into the standard library. -- Andrei

On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu wrote:
> I think we need to promote the best of the breed into the standard library. -- Andrei

True that for anything not too subjective (XML, json, streams), but for frameworks it might be healthier to leave decisions open. And we shouldn't hurry with choosing libraries. Some real-world testing and some alternative implementations are good for natural selection.

On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu wrote:
> On 1/30/15 5:41 AM, Martin Nowak wrote:
>>
>> Leave the better part of this to freestanding libraries, they prosper
>> much better.
>>
>> 14 database drivers
>> http://code.dlang.org/?sort=updated&category=library.database
>> 24 networking libraries
>> http://code.dlang.org/?sort=updated&category=library.network
>> 5 JSON libraries
>> http://code.dlang.org/search?q=json
>>
>> A lot of them are quite good and it has become really simple to write a
>> nice library that is well tested and documented.
>> I try to maintain this library as state-of-the-art D project
>> with dub, ddox, travis-ci and doveralls integration.
>>
>> https://github.com/MartinNowak/bloom
>
> I think we need to promote the best of the breed into the standard library. -- Andrei

Most of those are much better were they are.

On 1/30/15 9:17 PM, Dicebot wrote:
> On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu wrote:
>> On 1/30/15 5:41 AM, Martin Nowak wrote:
>>>
>>> Leave the better part of this to freestanding libraries, they prosper
>>> much better.
>>>
>>> 14 database drivers
>>> http://code.dlang.org/?sort=updated&category=library.database
>>> 24 networking libraries
>>> http://code.dlang.org/?sort=updated&category=library.network
>>> 5 JSON libraries
>>> http://code.dlang.org/search?q=json
>>>
>>> A lot of them are quite good and it has become really simple to write a
>>> nice library that is well tested and documented.
>>> I try to maintain this library as state-of-the-art D project
>>> with dub, ddox, travis-ci and doveralls integration.
>>>
>>> https://github.com/MartinNowak/bloom
>>
>> I think we need to promote the best of the breed into the standard
>> library. -- Andrei
>
> Most of those are much better were they are.

Clearly this is a matter in which reasonable people can disagree. It is my opinion that more functionality in the standard library is the right strategy for D.

Andrei