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
On 12/23/2013 02:39 AM, 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 (beca
On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
How is this going to be implemented? In a similar way as this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804
Without `alias this` part (that would destroy "no auto expansion"
part unless I miss something). Also I am still u
On 12/23/2013 03:28 AM, Dicebot wrote:
On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
How is this going to be implemented? In a similar way as this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804
Without `alias this` part (that would destroy "no auto expansion" part
No
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
Are you seriously suggesting we change the auto-expanding
behaviour of template argument lists? This is going to cause the
biggest code breakage since D2, for the niche benefit of having
lists that don't
On Mon, Dec 23, 2013 at 01:39:24AM +, 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
> picke
On Mon, Dec 23, 2013 at 02:46:38AM +, Jakob Ovrum wrote:
> On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> >http://wiki.dlang.org/DIP54
>
> Are you seriously suggesting we change the auto-expanding behaviour
> of template argument lists? This is going to cause the biggest code
>
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-expand
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.
On Monday, 23 December 2013 at 02:42:01 UTC, Timon Gehr wrote:
On 12/23/2013 03:28 AM, Dicebot wrote:
On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
How is this going to be implemented? In a similar way as
this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804
Without `a
On Mon, Dec 23, 2013 at 03:02:48AM +, 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 cl
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 langua
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
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 ju
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 ju
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 ju
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 w
On 12/23/13, Dicebot 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 frequent
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 Phob
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
On Monday, 23 December 2013 at 10:15:19 UTC, ilya-stromberg wrote:
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
On 12/23/2013 04:02 AM, 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
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct
is misleading.
Can explain this a bit? What makes one miss distinction between
language term and library type? (Hint: latter is denoted by
CamelCase ;))
On Monday, 23 December 2013 at 03:45:07 UTC, Jakob Ovrum wrote:
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 this is the root cause of
On Monday, 23 December 2013 at 11:44:01 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 10:15:19 UTC, ilya-stromberg
wrote:
About `auto-expansion` problem: please add documentation that
describes difference between `auto-expansion TypeTuple` and
`TemplateArgumentList without auto-expansion`.
Jakob Ovrum:
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.
Plus built-in syntax to unpack tuples in various situations.
Bye,
bearophile
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
Can we add alias for `auto-expansion TypeTuple` and add link to
the previous documentation like this:
alias ExpandedTemplateArgumentList(T) =
TemplateArgumentList!(T).expand;
It looks like it can fix all objections here.
Wh
On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg
wrote:
Can we add alias for `auto-expansion TypeTuple` and add link
to the previous documentation like this:
alias ExpandedTemplateArgumentList(T) =
TemplateArgumentList!(T)
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
Full support. Never used tuple or TypeTuple since I don't
understand what they are for, and their precise relationship to
templated argument lists. Better names will help.
A code breakage with a compilati
On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg
wrote:
Can we add alias for `auto-expansion TypeTuple` and add link
to the previous documentation like this:
alias ExpandedTemplateArgumentList(T) =
TemplateArgumentList!(T)
On Monday, 23 December 2013 at 13:13:13 UTC, monarch_dodra wrote:
On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg
wrote:
Can we add alias for `auto-expansion TypeTuple` and add link
to the previous documentation like this:
5 Algorithms from `std.typetuple` are re-written to accept
non-expanding template argument lists and form base for
`std.meta.` package.
Why? This seems to me like it would create duplication for
nothing. These templates would do the expanding themselves?
Unless I'm mistaken, the `TemplateArg
On Monday, 23 December 2013 at 13:23:39 UTC, monarch_dodra wrote:
5 Algorithms from `std.typetuple` are re-written to accept
non-expanding template argument lists and form base for
`std.meta.` package.
Why? This seems to me like it would create duplication for
nothing. These templates would d
On Monday, 23 December 2013 at 11:58:06 UTC, Dicebot wrote:
Also having both types at the same time will cause difficulties
with template algorithms currently present in std.typetuple -
having some defined in terms of raw argument list and others in
terms of packed TemplateArgumentList is just
On Monday, 23 December 2013 at 11:59:34 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct
is misleading.
Can explain this a bit? What makes one miss distinction between
language term and library typ
On Monday, 23 December 2013 at 13:41:07 UTC, Maxim Fomin wrote:
On Monday, 23 December 2013 at 11:59:34 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct
is misleading.
Can explain this a bit? What
On 2013-12-23 01:39:24 +, "Dicebot" said:
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 f
On Monday, 23 December 2013 at 13:31:36 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 13:23:39 UTC, monarch_dodra
eg:
staticIndexOf(int, TemplateArgumentList!(int, double), int);
Produces 1? 2? 3?
I really don't know.
Compile-time error, new `staticIndexOf` will strictly accept 2
templa
Disclaimer: I am a newbie and I have *almost* understood the
difference between built-in tuples, Tuple and TypeTuple. Almost.
I'll have to get back to you on that. I also have some bad
history with auto-expansion from my work with bash scripts, but
that's for me and my therapist.
On Monday, 2
On Monday, 23 December 2013 at 13:58:13 UTC, JR wrote:
... I have *almost* understood the difference between built-in
tuples, Tuple and TypeTuple.
I had this feeling probably 5 or 6 times in past few years, only
to find some new surprise every time :D Can only hope that
finally got it right i
On Monday, 23 December 2013 at 13:50:26 UTC, monarch_dodra wrote:
Ok... Then that'll break existing code that doesn't even *use*
TypeTuple... Seems lose-lose to me :/
Yes, this DIP defines breaking transition that requires user
action at some point. It is expected and approved by Andrei - we
On Monday, 23 December 2013 at 14:00:21 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 13:50:26 UTC, monarch_dodra
wrote:
Ok... Then that'll break existing code that doesn't even *use*
TypeTuple... Seems lose-lose to me :/
Yes, this DIP defines breaking transition that requires user
actio
On Monday, 23 December 2013 at 15:34:07 UTC, monarch_dodra wrote:
You proposal
(this is still all about your proposal 5), wants to make
std.typetuple use TAL's in all their implementations.
I mean "interface".
On 12/23/2013 12:59 PM, Dicebot wrote:
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct is
misleading.
Can explain this a bit? What makes one miss distinction between language
term and library type?
(It is not a type
On Monday, 23 December 2013 at 15:59:10 UTC, Timon Gehr wrote:
As is the former. :P
http://dlang.org/template.html#TemplateArgumentList
I think using the name TemplateArgumentList for anything other
than a shallow wrapper around a template argument list does not
actually improve the naming si
On 12/23/13, Dicebot wrote:
> http://wiki.dlang.org/DIP54
I'm waiting to see what others who use TypeTuples think of the DIP.
E.g. Philippe Sigaud, David Nadlinger, Hara Kenji, Martin Nowak, Don
Clugston, David Simcha, Steven Schveighoffer, etc. I'm pretty sure
(most) of these guys use tuples a l
On Mon, Dec 23, 2013 at 02:04:52PM +, Dicebot wrote:
> On Monday, 23 December 2013 at 13:58:13 UTC, JR wrote:
> >... I have *almost* understood the difference between built-in
> >tuples, Tuple and TypeTuple.
>
> I had this feeling probably 5 or 6 times in past few years, only to
> find some ne
On 12/23/13 4:25 AM, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
Can we add alias for `auto-expansion TypeTuple` and add link to the
previous documentation like this:
alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
It looks like it
On 12/23/13 4:07 AM, bearophile wrote:
Jakob Ovrum:
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.
Plus built-in syntax to unpack tuples in various situations.
I don't think "various situations" is a good
On 12/23/13 5:41 AM, Maxim Fomin wrote:
Personally I am upset when I get some weird Phobos structure which
simulates language feature, rathen then having feature in the language
in first place.
It's a fine line to thread. Erring on either side is easy and with bad
consequences.
Andrei
On Mon, Dec 23, 2013 at 04:30:14PM -0800, Andrei Alexandrescu wrote:
> On 12/23/13 5:41 AM, Maxim Fomin wrote:
> >Personally I am upset when I get some weird Phobos structure which
> >simulates language feature, rathen then having feature in the
> >language in first place.
>
> It's a fine line to
Andrei Alexandrescu:
I don't think "various situations" is a good idea. It often
does make code shorter. But it means more rules to be defined,
implemented, and taught.
Here I have written "various situations" because I have given a
list of those "various situations" in past posts.
I think t
H. S. Teoh:
Personally, I'm for simplifying the core language and moving
non-essentials out to the standard library
How do you define "essential"?
- Frequently used;
- The compiler can compile it as efficiently as handwritten code;
- Has a sufficiently clean semantics, that is most times the o
On Tue, Dec 24, 2013 at 01:05:26AM +, bearophile wrote:
> H. S. Teoh:
>
> >Personally, I'm for simplifying the core language and moving
> >non-essentials out to the standard library
>
> How do you define "essential"?
> - Frequently used;
I don't think 'frequently used' is sufficient to justi
I think this is just getting absurd.
The conflation between the naming issue and auto-expansion is so
bloody dishonest. The DIP looks really good to newbies because it
addresses the former but then they don't really understand the
latter (as some have even said explicitly). Further, if this DI
On Tue, Dec 24, 2013 at 02:52:18AM +, Jakob Ovrum wrote:
> I think this is just getting absurd.
>
> The conflation between the naming issue and auto-expansion is so
> bloody dishonest. The DIP looks really good to newbies because it
> addresses the former but then they don't really understand
On Tuesday, 24 December 2013 at 04:08:25 UTC, H. S. Teoh wrote:
So if we only implemented the first part of the DIP, the
renaming of
std.typeconds.TypeTuple -> std.meta.list (or whatever, let's
not start
bikeshedding this early), along with the documentation cleanup
which is
long overdue anyw
On Tuesday, 24 December 2013 at 04:48:57 UTC, Jakob Ovrum wrote:
[1] Assuming that the case for non-auto-expanding lists can be
argued sufficiently for inclusion in Phobos, which is yet to be
seen. This DIP doesn't seem to even try.
Clarification: "Assuming that the case for non-auto-expanding
On 12/23/13 7:34 AM, monarch_dodra wrote:
My issue about this is that it will break existing code that doesn't
even use the type "TypeTuple". What are the gains of:
anySatisfy!(someTrait, TemplateArgumentList!(int, double));
over
anySatisfy!(someTrait, int, double)
Or
anySatisfy!(someTrait, Te
On 12/23/13 8:21 AM, monarch_dodra wrote:
On Monday, 23 December 2013 at 15:59:10 UTC, Timon Gehr wrote:
As is the former. :P
http://dlang.org/template.html#TemplateArgumentList
I think using the name TemplateArgumentList for anything other than a
shallow wrapper around a template argument lis
On Mon, Dec 23, 2013 at 7:34 PM, Andrej Mitrovic
wrote:
> I'm waiting to see what others who use TypeTuples think of the DIP.
> E.g. Philippe Sigaud, David Nadlinger, Hara Kenji, Martin Nowak, Don
> Clugston, David Simcha, Steven Schveighoffer, etc. I'm pretty sure
> (most) of these guys use tuple
24-Dec-2013 04:57, bearophile пишет:
Andrei Alexandrescu:
It often does make code shorter.
It also avoids the programmer to think about useless details, leaving
more brain for more important things. Assigning the fields to variables
like this:
const uselessTmp = foo();
immutable something = u
24-Dec-2013 09:00, Jakob Ovrum пишет:
On Tuesday, 24 December 2013 at 04:48:57 UTC, Jakob Ovrum wrote:
[1] Assuming that the case for non-auto-expanding lists can be argued
sufficiently for inclusion in Phobos, which is yet to be seen. This
DIP doesn't seem to even try.
Clarification: "Assumin
On Tuesday, 24 December 2013 at 10:30:47 UTC, Dmitry Olshansky
wrote:
As long as algorithms that operate say on 2 lists expect
arguments to have '.expand' we'd be in a good shape just
providing a `packList` or some such together with `list`.
I think so too. Of course, it is predicated on the f
On 12/29/13 3:09 AM, Dicebot wrote:
1)
Timon has raised the point that exact match between in naming between
built-in and library type will be confusing as they will actually differ
in behavior (http://forum.dlang.org/post/l99mke$q1o$1...@digitalmars.com).
Andrei has proposed `TemplateArgumentPac
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu
wrote:
On 12/29/13 3:09 AM, Dicebot wrote:
1)
Timon has raised the point that exact match between in naming
between
built-in and library type will be confusing as they will
actually differ
in behavior
(http://forum.dlang.org/pos
On Sunday, 29 December 2013 at 11:10:00 UTC, Dicebot wrote:
Despite my initial desire to standardize API between library
types it seems that breakage will be much more damaging than I
have initially expected. Jakob example
(http://forum.dlang.org/post/vkeqyorptcobufzmm...@forum.dlang.org)
does
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu
wrote:
I think a duo `TemplateArgumentList` (auto-expansion) and
`TemplateArgumentPack` (no auto-expansion) in the same module
is the ticket. It also makes for a wonderful opportunity to
explain the distinction in the documentatio
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu
wrote:
I think a duo `TemplateArgumentList` (auto-expansion) and
`TemplateArgumentPack` (no auto-expansion) in the same module
is the ticket. It also makes for a wonderful opportunity to
explain the distinction in the documentatio
On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
...
Sorry, can you make a short summary about your position? You are
against adding packed list to library or just against removing
expanding one (from the library)?
On Sunday, 29 December 2013 at 15:45:59 UTC, Dicebot wrote:
On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
...
Sorry, can you make a short summary about your position? You
are against adding packed list to library or just against
removing expanding one (from the library)?
On 12/29/13 7:42 AM, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
I think a duo `TemplateArgumentList` (auto-expansion) and
`TemplateArgumentPack` (no auto-expansion) in the same module is the
ticket. It also makes for a wonderful opportunity to expl
On Sunday, 29 December 2013 at 16:01:41 UTC, Andrei Alexandrescu
wrote:
I also think it should be shorter, because a) it's a
fundamental, and
thus very commonly used template, and b) code that manipulates
lists are
functional in nature which results in long lines that are also
hard to
split up
On 12/29/13 8:14 AM, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 16:01:41 UTC, Andrei Alexandrescu wrote:
I also think it should be shorter, because a) it's a fundamental, and
thus very commonly used template, and b) code that manipulates lists are
functional in nature which results in lon
On Sunday, 29 December 2013 at 16:19:57 UTC, Andrei Alexandrescu
wrote:
It's been discussed before - these are advanced notions that
won't be used frequently and naively.
I guess I'm biased by writing a lot of library code, where it's
quite frequently used. I can imagine application code using
29-Dec-2013 20:01, Andrei Alexandrescu пишет:
On 12/29/13 7:42 AM, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
I also think it should be shorter, because a) it's a fundamental, and
thus very commonly used template, and b) code that manipulates lists
On Sunday, 29 December 2013 at 19:02:57 UTC, Dmitry Olshansky
wrote:
And having to deal with all kinds of aliases people are
_expected_ to create? Why not pick something accessible in the
first place?
Because no good short name has ever been proposed so far. I'd
strongly discourage creating p
Back to fighting :)
On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
Breakage that causes errors in secondary locations and cannot
be automatically repaired (e.g. search & replace) is the worst
kind of breakage, after silent failures, that I can think of.
This is why I have con
On 12/29/2013 10:41 PM, Dicebot wrote:
...
"Use in static foreach" - works with alias this
"Use in special expressions that operate on types, such as `is`,
`typeof` and `typeid`" - any code that does on expanded lists right now
is completely broken and must be re-written according to existing sp
On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
I think we should use this chance to rectify the capitalization
of the name. As the result is not exclusively a list of types,
current conventions state that the name should be
lowerCamelCase.
I believe you got this one the wrong
On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
I think we should use this chance to rectify the capitalization
of the name. As the result is not exclusively a list of types,
current conventions state that the name should be
lowerCamelCase.
I believe you got this one the wrong
On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
What would be an example of code that you consider to be broken?
(TemplateArgumentList!(int, double) is a valid type and
TemplateArgumentList!(1, 2.0) is a value of that type.)
Stuff that relies that, for example, that `is(TypeTupl
On Monday, 30 December 2013 at 01:36:48 UTC, David Nadlinger
wrote:
On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
I think we should use this chance to rectify the
capitalization of the name. As the result is not exclusively a
list of types, current conventions state that the n
On Monday, 30 December 2013 at 03:01:08 UTC, Dicebot wrote:
Do we actually have guidelines about casing in context of
aliased content? I had impression that it is symbol on its own
that matters and thus TemplateArgumentPack needs to be
CamelCased simply because it is a type/template, whatever i
On Monday, 30 December 2013 at 03:19:36 UTC, David Nadlinger
wrote:
On Monday, 30 December 2013 at 03:01:08 UTC, Dicebot wrote:
Do we actually have guidelines about casing in context of
aliased content? I had impression that it is symbol on its own
that matters and thus TemplateArgumentPack nee
On 12/30/2013 03:58 AM, Dicebot wrote:
On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
What would be an example of code that you consider to be broken?
(TemplateArgumentList!(int, double) is a valid type and
TemplateArgumentList!(1, 2.0) is a value of that type.)
Stuff that reli
On 12/29/13 6:58 PM, Dicebot wrote:
On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
What would be an example of code that you consider to be broken?
(TemplateArgumentList!(int, double) is a valid type and
TemplateArgumentList!(1, 2.0) is a value of that type.)
Stuff that relies
On Monday, 30 December 2013 at 03:44:49 UTC, Andrei Alexandrescu
wrote:
I don't understand the question. I think there's no particular
relation between TemplateArgument{List,Pack}!(int, double) and
TemplateArgument{List,Pack}!(1, 2.0). One is a list of two
types and the other is a list of two v
On 12/30/2013 04:44 AM, Andrei Alexandrescu wrote:
I don't understand the question. I think there's no particular relation
between TemplateArgument{List,Pack}!(int, double) and
TemplateArgument{List,Pack}!(1, 2.0). One is a list of two types and the
other is a list of two values, and yah, if you
On Monday, 30 December 2013 at 03:37:56 UTC, Timon Gehr wrote:
It is in line with general rule of opXXX for structs working
as syntax
rewrite.
No, it is not.
"No" as in "not in line" or "you interpret rules wrong"?
Me too. Maybe it should be addressed in general by defining
template-argume
On Monday, 30 December 2013 at 04:07:42 UTC, Timon Gehr wrote:
Template arguments lists are what they are - entities that can
be passed
to templates. Aliasing them is sensible but creating values
thereof does
not make sense.
You are doing it in the implementation of std.typecons.Tuple,
and o
On 12/30/2013 05:11 AM, Dicebot wrote:
On Monday, 30 December 2013 at 04:07:42 UTC, Timon Gehr wrote:
Template arguments lists are what they are - entities that can be passed
to templates. Aliasing them is sensible but creating values thereof does
not make sense.
You are doing it in the implem
On 12/30/2013 05:08 AM, Dicebot wrote:
On Monday, 30 December 2013 at 03:37:56 UTC, Timon Gehr wrote:
It is in line with general rule of opXXX for structs working as syntax
rewrite.
No, it is not.
"No" as in "not in line" or "you interpret rules wrong"?
...
Both. There is no precedent for
On Monday, 30 December 2013 at 04:25:22 UTC, Timon Gehr wrote:
If you are going to claim that this is not proper creation of
an instance of a type, except that:
int x;
static assert(is(typeof(x)==int));
Seq!(int, double) y;
static assert(is(typeof(y)==Seq!(int, double))); // presumably
"bad"
On Monday, 30 December 2013 at 04:35:04 UTC, Timon Gehr wrote:
Both. There is no precedent for rewriting operator arguments to
template value arguments neither in the spec, in newsgroup
discussions on the design of a potential feature, nor in the
implementation. You seemed to claim this is mere
On 12/30/2013 05:55 AM, Dicebot wrote:
Ah I was referring to the fact that it does not seem to compile even
assuming normal non-template parameters as indexes (which looks like a
bug). Other part (which is real desired one) is not allowed by spec
right now indeed.
struct X
{
static int opS
On 12/30/2013 05:51 AM, Dicebot wrote:
On Monday, 30 December 2013 at 04:25:22 UTC, Timon Gehr wrote:
If you are going to claim that this is not proper creation of an
instance of a type, except that:
int x;
static assert(is(typeof(x)==int));
Seq!(int, double) y;
static assert(is(typeof(y)==Seq
On 12/29/13 8:03 PM, Dicebot wrote:
It is yet another special case that makes template argument list act as
first class type despite not being one.
Oh, I see. Yah, that's odd but then such is life. I think it's a
tolerable special case.
If it is you judgement, let it be so. I prefer to star
On 12/29/13 8:07 PM, Timon Gehr wrote:
On 12/30/2013 04:44 AM, Andrei Alexandrescu wrote:
I don't understand the question. I think there's no particular relation
between TemplateArgument{List,Pack}!(int, double) and
TemplateArgument{List,Pack}!(1, 2.0). One is a list of two types and the
other
On 12/29/13 8:25 PM, Timon Gehr wrote:
On 12/30/2013 05:11 AM, Dicebot wrote:
On Monday, 30 December 2013 at 04:07:42 UTC, Timon Gehr wrote:
Template arguments lists are what they are - entities that can be
passed
to templates. Aliasing them is sensible but creating values thereof
does
not make
1 - 100 of 125 matches
Mail list logo
