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



--- Comment #10 from monarchdodra@gmail.com 2013-10-10 00:50:45 PDT ---
(In reply to comment #8)
> It seems you starting to understand the issue (but I haven't thought whether static arrays are only types supporting this).

OK. What about this...? Is it a bug?

//----
struct S
{
  int[1] arr;
}

void main()
{
  uint[]  udarr;
  uint[1] usarr;

  int[1] arr1 = udarr; //OK
  int[1] arr2 = usarr; //OK
  S s1 = S(udarr); //NOPE?
  S s2 = S(usarr); //NOPE?
}
//----

I'm not challenging you, I'm really just trying to understand the rules.

> Anyway this feature was working for years.

I make no claim to the contrary. Original confusion comes from what I saw as "inconsistent", and made the "upside down conclusion". I guess I should have filed instead (maybe) that AGG!S(1) should be legal.

-- 
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=11206



--- Comment #11 from Kenji Hara <k.hara.pg@gmail.com> 2013-10-10 01:15:51 PDT ---
(In reply to comment #9)
> As I have mentioned previously, there is no inconsistency because you implicitly assuming that struct literal/constructors can be recursive or 'nested' in some sense. If you mean allowing AGG!S ts1 = AGG!S(1); in original example, then this is a minor enhancement.

I knot that it is an enhancement (eg. bug 7255), but I think it's necessary to increase consistency between static array and user-defined struct type, and it's important for more expressiveness on initializing.

The start of my thought ----
Currently, BigInt accepts built-in integers as the "valid initializer".

  BigInt num = 1;

This is expressive syntax. But, when you declare a multi-dimensional array of BigInt, it would become too verbose.

  BigInt[128] sa = [
      BigInt(1), BigInt(2), BigInt(3), BigInt(4),
      BigInt(5), BigInt(6), BigInt(7), BigInt(8),
      ...
  ];

If T t = v; is allowed, array initializer should also allow T[n] tsa = [v1, v2, ...]; After the enhancement implemented, we will be able to write the BigInt array declaration as:

  BigInt[128] sa = [1, 2, 3, 4, 5, 6, 7, 8, ..., 128];

---- The end of my thought

I think we could apply the same rule to the relation of struct literal syntax arguments and corresponding struct field type.

  Agg!S agg = Agg!S(1);  // #1
  S[1] ssa = [1];    // #2

- In #1, the struct field Agg!S.val is initialized by the corresponding value 1
which is in the struct literal argument list.
- In #2, the array element ssa[1] is initialized by the corresponding value 1
which is in the array initializer argument list.

In both case, if the initialized storage typed S accepts the corresponding value 1 *as the valid initializer*, the composite array/struct initializing should also work.

Additional note: The following code already works currently.

  Agg!S aggr2 = {val:1};   // struct initializer syntax

-- 
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=11206


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |
           Severity|normal                      |enhancement


--- Comment #12 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-10-10 01:32:06 PDT ---
(In reply to comment #11)
> (In reply to comment #9)
> > As I have mentioned previously, there is no inconsistency because you implicitly assuming that struct literal/constructors can be recursive or 'nested' in some sense. If you mean allowing AGG!S ts1 = AGG!S(1); in original example, then this is a minor enhancement.
> 
> I knot that it is an enhancement (eg. bug 7255), but I think it's necessary to increase consistency between static array and user-defined struct type, and it's important for more expressiveness on initializing.
> 
> The start of my thought ----
> Currently, BigInt accepts built-in integers as the "valid initializer".
> 
>   BigInt num = 1;
> 
> This is expressive syntax. But, when you declare a multi-dimensional array of BigInt, it would become too verbose.
> 
>   BigInt[128] sa = [
>       BigInt(1), BigInt(2), BigInt(3), BigInt(4),
>       BigInt(5), BigInt(6), BigInt(7), BigInt(8),
>       ...
>   ];
> 
> If T t = v; is allowed, array initializer should also allow T[n] tsa = [v1, v2, ...]; After the enhancement implemented, we will be able to write the BigInt array declaration as:
> 
>   BigInt[128] sa = [1, 2, 3, 4, 5, 6, 7, 8, ..., 128];
> 
> ---- The end of my thought

OK. I agree that there is room for improving support for implicit construction.

> I think we could apply the same rule to the relation of struct literal syntax arguments and corresponding struct field type.
> 
>   Agg!S agg = Agg!S(1);  // #1
>   S[1] ssa = [1];    // #2
> 

It looks like when you are speaking about struct literal syntax you mean both struct literal and struct constructors (probably even opCall). It seems that Agg!S(1) would be valid either if there is constructor taking int or first member is integer type. Do you consider documenting it after merging corresponding pull?

> - In #1, the struct field Agg!S.val is initialized by the corresponding value 1
> which is in the struct literal argument list.
> - In #2, the array element ssa[1] is initialized by the corresponding value 1
> which is in the array initializer argument list.
> 
> In both case, if the initialized storage typed S accepts the corresponding value 1 *as the valid initializer*, the composite array/struct initializing should also work.
> 
> Additional note: The following code already works currently.
> 
>   Agg!S aggr2 = {val:1};   // struct initializer syntax

OK. I changed type of the issue to show it is enhacement now.

-- 
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=11206


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid


--- Comment #13 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-10-10 01:46:55 PDT ---
(In reply to comment #10)
> (In reply to comment #8)
> > It seems you starting to understand the issue (but I haven't thought whether static arrays are only types supporting this).
> 
> OK. What about this...? Is it a bug?
> 
> //----
> struct S
> {
>   int[1] arr;
> }
> 
> void main()
> {
>   uint[]  udarr;
>   uint[1] usarr;
> 
>   int[1] arr1 = udarr; //OK
>   int[1] arr2 = usarr; //OK
>   S s1 = S(udarr); //NOPE?
>   S s2 = S(usarr); //NOPE?
> }
> //----
> 
> I'm not challenging you, I'm really just trying to understand the rules.

Integer arrays as initializers is completely different story. What you are trying was not supported and not documented. However, what is more important is that recently there was an enhacement request to support such conversions (I don't know issue number) or something similar and consensus was to allow it (probably there is a pull for it). Since Kenji is in thread he probably may clarify the situation.

(In general this is currently a dark territory of language.)

> 
> > Anyway this feature was working for years.
> 
> I make no claim to the contrary. Original confusion comes from what I saw as "inconsistent", and made the "upside down conclusion". I guess I should have filed instead (maybe) that AGG!S(1) should be legal.

OK, marked as rejects-valid.

-- 
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=11206


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |


--- Comment #14 from Kenji Hara <k.hara.pg@gmail.com> 2013-10-10 02:00:57 PDT ---
(In reply to comment #12)
> > I think we could apply the same rule to the relation of struct literal syntax arguments and corresponding struct field type.
> > 
> >   Agg!S agg = Agg!S(1);  // #1
> >   S[1] ssa = [1];    // #2
> > 
> 
> It looks like when you are speaking about struct literal syntax you mean both struct literal and struct constructors (probably even opCall). It seems that Agg!S(1) would be valid either if there is constructor taking int or first member is integer type. Do you consider documenting it after merging corresponding pull?

No. I strictly distinguish struct literal and struct constructor call.

struct S1 { int num; }                // S1(1) is literal syntax
struct S2 { this(int); }              // S2(1) is ctor call
struct S3 { static S3 opCall(int); }  // S3(1) is static function call

struct A1(T) { T val; }
struct A2(T) { this(T); }

void main()
{
    S1 s1 = 1;  // should be NG, int is not implicitly convertible to S1
    S2 s2 = 1;  // OK. The S2 ctor accepts int value as a valid initializer,
                // then it's implicitly invoked for initialization.
    S3 s3 = 1;  // NG. opCall is completely unrelated to initializing.

    // Note that A1!T(...) is always literal syntax
    A1!S1 a11 = A1!S1(1);  // NG, int is not implicitly convertible to S1
    A1!S2 a12 = A1!S2(1);  // should be OK, as same as the 's2' case.
    A1!S3 a13 = A1!S3(1);  // Of course NG.

    // Note that A2!T(...) is constructor call
    A2!S1 a21 = A2!S1(1);  // NG, int is not implicitly convertible to S1
    A2!S2 a22 = A2!S2(1);  // NG, int is not implicitly convertible to S1
    A2!S3 a23 = A2!S3(1);  // NG, int is not implicitly convertible to S1
}

-- 
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=11206



--- Comment #15 from Kenji Hara <k.hara.pg@gmail.com> 2013-10-10 02:21:30 PDT ---
(In reply to comment #10)
>   uint[]  udarr;
>   uint[1] usarr;
> 
>   int[1] arr1 = udarr; //OK
>   int[1] arr2 = usarr; //OK

Mmm...I think this is a bug. Because following code is also accepted in compilation, and will cause runtime exception!

void main()
{
  int[4] sa;
  ulong[4] sa2 = sa;
}

-- 
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=11206



--- Comment #16 from Kenji Hara <k.hara.pg@gmail.com> 2013-11-03 01:18:36 PST ---
(In reply to comment #15)
> (In reply to comment #10)
> >   uint[]  udarr;
> >   uint[1] usarr;
> > 
> >   int[1] arr1 = udarr; //OK
> >   int[1] arr2 = usarr; //OK
> 
> Mmm...I think this is a bug. Because following code is also accepted in compilation, and will cause runtime exception!
> 
> void main()
> {
>   int[4] sa;
>   ulong[4] sa2 = sa;
> }

I opened bug 11426. It is a regression issue from 2.061.

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