https://issues.dlang.org/show_bug.cgi?id=1654
--- Comment #31 from Steven Schveighoffer ---
I expect at some point for concatenation to be a fully lowered template
function, and at that point, we have all the tools to do this.
You can leave it open if you want, I was just looking through issues
https://issues.dlang.org/show_bug.cgi?id=1654
timon.g...@gmx.ch changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
https://issues.dlang.org/show_bug.cgi?id=1654
Steven Schveighoffer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=1654
Ivan Timokhin changed:
What|Removed |Added
CC||timokhin...@gmail.com
--
https://issues.dlang.org/show_bug.cgi?id=1654
Sobirari Muhomori changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=1654
Marc Schütz changed:
What|Removed |Added
CC||schue...@gmx.net
--
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #28 from bearophile_h...@eml.cc 2013-05-31 11:57:29 PDT ---
An example of code we like to compile:
void main() {
immutable data1 = [10, 20];
immutable data2 = data1 ~ [30];
}
--
Configure issuemail: http://d.puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #27 from Kenji Hara 2013-04-27 22:50:37 PDT
---
I think this is doable enhancement with sane rule.
>From 2.061, we have a 'unique expression' in certain cases.
pure int[] newArr(int n) { return new int[](n); }
immutable int[]
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #26 from timon.g...@gmx.ch 2013-04-27 17:43:43 PDT ---
(In reply to comment #24)
> (In reply to comment #23)
>
> > Because user-defined types would want to define it to behave similar as for
> > arrays.
>
> In this case I think a l
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #25 from bearophile_h...@eml.cc 2013-04-27 06:57:04 PDT ---
(In reply to comment #24)
> In this case I think a little amount of magic is acceptable (if it's
> necessary).
because in my opinion the gain from accepting code like this
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #24 from bearophile_h...@eml.cc 2013-04-27 06:53:14 PDT ---
(In reply to comment #23)
> Because user-defined types would want to define it to behave similar as for
> arrays.
In this case I think a little amount of magic is acceptab
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #23 from Andrei Alexandrescu 2013-04-27
06:18:26 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
>
> > It's obvious - magic is bad etc.
>
> But array concat is a built-in op. So why is some magic bad here?
Because
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #22 from bearophile_h...@eml.cc 2013-04-27 05:43:30 PDT ---
(In reply to comment #21)
> It's obvious - magic is bad etc.
But array concat is a built-in op. So why is some magic bad here?
--
Configure issuemail: http://d.puremagic
http://d.puremagic.com/issues/show_bug.cgi?id=1654
Andrei Alexandrescu changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #21 from Andrei
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #20 from bearophile_h...@eml.cc 2013-04-27 05:14:20 PDT ---
(In reply to comment #19)
> Whatever the solution to this is, it shouldn't make
> operator ~ magic, i.e. the behavior should be implementable as a regular
> function call.
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #19 from Andrei Alexandrescu 2013-04-27
04:19:53 PDT ---
Wow this is one old one. Whatever the solution to this is, it shouldn't make
operator ~ magic, i.e. the behavior should be implementable as a regular
function call.
--
Conf
http://d.puremagic.com/issues/show_bug.cgi?id=1654
yebblies changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #18 from yebb
http://d.puremagic.com/issues/show_bug.cgi?id=1654
yebblies changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #17 from
18 matches
Mail list logo
