http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #20 from bearophile_hugs@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.

Are you willing to explain why?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654


Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW


--- Comment #21 from Andrei Alexandrescu <andrei@erdani.com> 2013-04-27 05:31:43 PDT ---
(In reply to comment #20)
> (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.
> 
> Are you willing to explain why?

It's obvious - magic is bad etc.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #22 from bearophile_hugs@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.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #23 from Andrei Alexandrescu <andrei@erdani.com> 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 user-defined types would want to define it to behave similar as for arrays. Also, http://goo.gl/AZLXo

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #24 from bearophile_hugs@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 acceptable (if it's
necessary).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #25 from bearophile_hugs@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:


void main() {
    string s1 = "abc";
    char[] s2 = s1 ~ s1;
}


outweighs the disadvantages caused by an eventual small amount of magic.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #26 from timon.gehr@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 little amount of magic is acceptable (if it's
> necessary).

There is no reason to make it necessary.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #27 from Kenji Hara <k.hara.pg@gmail.com> 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[] arr = newArr(3);
  // newArr(3) creates an unique array, so it is implicitly convertible to
  // immutable

  class MyClass {}
  immutable MyClass c = new MyClass();
  // Raw NewExpression creates an unique object, so it is implicitly
convertible
  // to immutable.

From 2.063, qualified constructor supports creating 'unique object'.

  struct MyObj { this(int) pure {} }
  immutable MyObj *p = new MyObj(1);
  // this(int) pure makes 'unique object', so the created object is implicitly
  // convertible to immutable.

Based on the 'unique expression' concept, we can consider that an array concatenation creates 'unique expression' when some conditions are satisfied.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1654



--- Comment #28 from bearophile_hugs@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/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------