On Mon, Dec 23, 2013 at 03:02:48AM +0000, Dicebot wrote:
> On Monday, 23 December 2013 at 03:00:11 UTC, Jakob Ovrum wrote:
> >On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
> >>People who want auto-expanding template argument lists can still do this:
> >
> >It's not perfectly clear, but it looks to me that the DIP suggests removing the auto-expanding property of template argument lists.
> 
> No, it would have changed language feature which is deeply integrated with lot of stuff and thus is untouchable. This proposal is only about Phobos and documentation.

That's what I thought. To make template argument lists non-expanding would basically require a rewrite of the compiler, since it's deeply integrated into compiler internals right now. And it would result in a language so foreign to existing user code that it might well be D3. It *might* be a possibility in the far future when we're ready to talk about D3, but that doesn't seem likely for the next 10 years (at least).


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall

On Monday, 23 December 2013 at 02:46:40 UTC, Jakob Ovrum wrote:
> This DIP makes several unfounded assumptions. It assumes that the semantics of template argument lists are inherently hard to learn,

Hard? No. Complicated - yes, I see wrong assumptions being made all the time. But this is language failure and is not directly related to this DIP.

> and that removing the auto-expanding aspect will make them easier to learn.

I don't say that. I say that it will allow to avoid introduction of _third_ tuple type into Phobos which would have makes things even harder to learn.

> claims that it enables previously impossible algorithms.

Algorithm that operates on variadic amount of template argument lists can't be expressed with TypeTuple behavior.

> It claims to be a compromise derived from several previous discussions (without citing any),

That I admit of my failure but I was not able to find discussions in archive in time. I will do it and add those as links eventually.

> I hate to say this, but it looks a lot like your personal agenda against auto-expanding lists is tacked onto and conflated with the naming problem, which I think is disingenuous.

Well, if you will actually find those threads, you will see that I was in favor of auto-expanding behavior ;) It was Andrei who has convinced me.

> I don't agree. I think we'd be in good shape just by fixing the naming problem, which is a much less controversial change.

We can't afford to add even more "tuple" types in library.

> Please don't pull the argument-by-authority card. Private conversations that affect all of us like this need to die in a fire. We should consider this kind of thing the equivalent of tainted evidence.

I am merely implying that this is not yet another random DIP that will hang for eternity and that this discussion will have some practical consequences in very nearby future, whatever the final outcome is.

On Monday, 23 December 2013 at 03:17:27 UTC, Dicebot wrote:
> Hard? No. Complicated - yes, I see wrong assumptions being made all the time. But this is language failure and is not directly related to this DIP.

I don't think it's obvious that it's a language failure.

> I don't say that. I say that it will allow to avoid introduction of _third_ tuple type into Phobos which would have makes things even harder to learn.

It wouldn't be the third tuple type, it would be the second type of list.

> Algorithm that operates on variadic amount of template argument lists can't be expressed with TypeTuple behavior.

They would be amply supported by using the second type of list. Still, there are no examples of such algorithms presented by the DIP. Without substantial evidence, they are niche at best or virtually non-existent at worst (though I'm sure it's the former). In either case, I don't think they warrant conflation with auto-expanding lists.

> Well, if you will actually find those threads, you will see that I was in favor of auto-expanding behavior ;) It was Andrei who has convinced me.

Then I apologize, and retract my comment.

> We can't afford to add even more "tuple" types in library.

One tuple and two compile-time lists - where the auto-expanding one covers the vast majority of use cases - doesn't sound at all bad.

I think we can conclude that auto-expanding lists cover the vast majority of cases on the basis that all of Phobos and virtually all other libraries use auto-expanding lists to great effect without interface contrivances.

My argument comes down to the fact that I think the issue of auto-expansion is orthogonal to the naming issue; yes, I acknowledge it would be beneficial to solve both at once, but such an integrated solution is predicated on the fact that auto-expansion is an issue in the first place, which I don't think the DIP addresses sufficiently.

I *do* think it does sufficiently address the fact that the current naming scheme is a problem.

On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> http://wiki.dlang.org/DIP54
>
> This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)
>
> Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.
>
> Thanks for your attention.

Yes, this is great. Anything to take tuples a step in the right direction. I'm immensely glad that TemplateArgumentList will not have auto-expansion by default, too.

On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> http://wiki.dlang.org/DIP54
>
> This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)
>
> Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.
>
> Thanks for your attention.

This is great.

My implementation of this, recently updated: https://github.com/John-Colvin/meta-d

On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> http://wiki.dlang.org/DIP54
>
> This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)
>
> Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.
>
> Thanks for your attention.

It's great thank you.

I totally agree that `TypeTuple` name is a problem,
`TemplateArgumentList` looks much better.

About `auto-expansion` problem: please add documentation that
describes difference between `auto-expansion TypeTuple` and
`TemplateArgumentList without auto-expansion`. I personally don't
know any difference, probably because I didn't write too
complicated meta code.

Also, can we keep bouth `auto-expansion TypeTuple` and
`TemplateArgumentList whitout auto-expansion` (maybe, in a
different module)? Or, maybe, can we add documentation how to
convert any  `auto-expansion TypeTuple` to the
`TemplateArgumentList without auto-expansion`.

Thanks.

On Monday, 23 December 2013 at 09:14:46 UTC, John Colvin wrote:
> On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
>> http://wiki.dlang.org/DIP54
>>
>> This is follow-up of several hot discussion threads that have happened several months ago. It has become pretty clear that there is no good way out of existing situation and least bad needs to be picked just to move forward (because it still be better than current horrible one)
>>
>> Linked proposal was discussed in short e-mail conversation with Andrei (with silent observation with Walter) and is mostly pre-approved. I am interested in general opinion of community and suggestions for any smaller tweaks before starting to work on pull requests.
>>
>> Thanks for your attention.
>
> This is great.
>
> My implementation of this, recently updated: https://github.com/John-Colvin/meta-d

Notes:

I haven't put the new names in yet, Pack -> TemplateArgumentList (personally I prefer Pack, as it isn't the same as a template argument list)

Having Pack in a template mixin is only needed for the opDispatch ufcs stuff. It could be dropped.

The meta.algorithm module is incomplete compared to std.algorithm

I still include Seq (i.e. TypeTuple). Sometimes a true template argument list is needed.

On 12/23/13, Dicebot <public@dicebot.lv> wrote:
> http://wiki.dlang.org/DIP54

Quoting:

----
There is also a private `std.typetuple.Pack` which is similar to current `std.typetuple.Tuple` but does not auto-expand. It is a tool absolutely necessary for more complex algorithms used in metaprogramming >>and is frequently re-invented in user libraries / projects<<.
----

If you simply remove the auto-expanding TypeTuple you will force coders to reinvent it. This may not seem like a big deal since you can simply do "alias List(T..) = T;", but it's a convenience template that should stay in Phobos.

Think of it like the range primitives of arrays that are implemented in std.array. I would hate to have to re-implement empty/front/popFront/etc for arrays every time I used them if they suddenly went missing in Phobos, even if they're very trivial to implement. Especially when all of my code already depends on those functions being there.

If we keep an auto-expanding TypeTuple template (but perhaps rename it), then all the user has to do to keep his code working is to do a global search & replace (transition is simple). It does still break code however.

But if you remove it entirely, the user has to add his own TypeTuple template in another module, and then he has to add new import declarations in every module that used TypeTuples. That's even worse than renaming.

---

Personally, I think the proper approach is:

1. Keep TypeTuple, but perhaps schedule it for renaming.
2. Introduce non-expanding equivalent to TypeTuple (in other words:
make Pack public, but maybe with a different name though).
3. Add a set of documentation clearly explaining the difference
between the various tuple types in Phobos and the languaage.

It seems to me that it's really the #3 that is the root cause of confusion, as #2 is an additive change that doesn't break any code but introduces something people were reinventing in their own libraries.

The real cause of people wanting #1 is #3, the lack of proper documentation. I have not had any problems understanding what the TypeTuple template means and how it relates to Tuple as soon as I started using both more frequently. If we have proper docs, we could even link to it from the documentation of all the tuple types in Phobos.

If we fix #2 and #3 I believe we'll have an improved situation and happy **current** users, as no code will break. Maybe absolute newbies will take a while to learn the difference between these various templates, but that's what tutorials/documentation is supposed to help with.

---

We always seem to forget that all newbies will eventually become experienced current users. Current (experienced) users need a little respect as well, not everything has to be tailored to the next batch of newbies by breaking existing users' code. Documentation and tutorials are the solutions here.

I vote against this DIP.

On Monday, 23 December 2013 at 11:08:26 UTC, Andrej Mitrovic
wrote:
> If you simply remove the auto-expanding TypeTuple you will force
> coders to reinvent it. This may not seem like a big deal since you can
> simply do "alias List(T..) = T;", but it's a convenience template that
> should stay in Phobos.

This is not really true. Any instance of `TypeTuple!(a, b, c)`
can be replaced with `TemplateArgumentList!(a, b, c).expand` with
no additional changes or definition of custom wrappers. Such
shortcut other way around is not possible - this is exactly why
having single non-expanding entity can work.

It does make you type more in metaprogramming code but this is
relatively small inconvenience that is faster to make than to
argue about. Before writing this DIP I have tested it on some of
my own template-heavy code to get an impression how it may look
like.

On Monday, 23 December 2013 at 11:08:26 UTC, Andrej Mitrovic wrote:
> We always seem to forget that all newbies will eventually become
> experienced current users. Current (experienced) users need a little
> respect as well, not everything has to be tailored to the next batch
> of newbies by breaking existing users' code. Documentation and
> tutorials are the solutions here.

And experienced users tend to overrate value of their own habits ;) Your point would have been strong if it was some fundamental inconvenience blocking certain power use cases. However in this scenario it is just matter of litle extra typing buried deep inside generic libraries. I think I can call myself metaprogramming power user too but I am eager to to those micro extra efforts for the sake of standard library simplicity.

Also while assumption that everyone will eventually become experienced user is true, not everyone will eventually be dealing with template algorithms - it is mostly business of library writers. And this newsgroup can give wrong impression about amount of library writers relatively to general user count :)