April 16, 2012
struct AB
{
	int a;
	int b;
	int [] numbers;
}

int main()
{
	int a = 300;
	const int [] numbers = new int[2];
	const AB c = {a,20, numbers};		// line 66
    writeln(c);
	return 0;
}

----------------------------
-debug
-unittest

src/main.d(66): Error: cannot implicitly convert expression (numbers) of type const(int[]) to int[]

---------------------------


const AB c;

	typeof(c.a)	is  const(int);
	typeof(c.numbers) is const(int []);


Shouldn't the code above accept the const(int [])   ?

April 16, 2012
sclytrack:

> struct AB
> {
> 	int a;
> 	int b;
> 	int [] numbers;
> }
>
> int main()
> {
> 	int a = 300;
> 	const int [] numbers = new int[2];
> 	const AB c = {a,20, numbers};		// line 66
>     writeln(c);
> 	return 0;
> }
>
> ----------------------------
> -debug
> -unittest
>
> src/main.d(66): Error: cannot implicitly convert expression (numbers) of type const(int[]) to int[]
>
> ---------------------------
>
>
> const AB c;
>
> 	typeof(c.a)	is  const(int);
> 	typeof(c.numbers) is const(int []);
>
>
> Shouldn't the code above accept the const(int [])   ?

I think you are asking too much to the poor type system. You are giving a const dynamic array (that's not a value) to assign it to a mutable variable, and then you want to assign the result to a const value. The type system is not able to perform those jumps.

But this seems to work:

struct AB {
    int a, b;
    int [] numbers;
}
void main() {
    import std.stdio;
    int a = 300;
    const numbers = new int[2];
    const c = const(AB)(a, 20, numbers);
    writeln(c);
}

Bye,
bearophile
April 16, 2012
> const numbers = new int[2];
> const c = const(AB)(a, 20, numbers);
> writeln(c);
> }
>
> Bye,
> bearophile

That's exactly what I needed, thanks.
April 16, 2012
On 04/16/2012 08:15 PM, sclytrack wrote:
>
>> const numbers = new int[2];
>> const c = const(AB)(a, 20, numbers);
>> writeln(c);
>> }
>>
>> Bye,
>> bearophile
>
> That's exactly what I needed, thanks.

Seems to be forwarded to the constructor if there is one.


(untested code)

struct B
{
	int [] _list;
		
	this( const int [] list) const
	{
		_list = list;
		//typeof(_list)=int []
		//typeof(list) =const(int[])

	}
}



Because of the const on the back of the constructor.
Normally  the typeof(_list) should be const(int[])
but assignable once, because we are in the constructor.


But a mutable design has been chosen (_list is int [])
until it is baked or cooked
or whatever the terminology. (don't have Andrei's book)
Probably for flexibility. Are there people out there
using this flexibility?

Just pondering,

	Sclytrack
April 16, 2012
On 04/16/2012 06:49 PM, bearophile wrote:
> sclytrack:
>
...
>>
>> Shouldn't the code above accept the const(int [])   ?
>

I think it is a bug that it does not.

> I think you are asking too much to the poor type system. You are giving
> a const dynamic array (that's not a value) to assign it to a mutable
> variable, and then you want to assign the result to a const value. The
> type system is not able to perform those jumps.
>

What he is asking for are initializer list struct literals for qualified struct types.

> But this seems to work:
>
> struct AB {
>      int a, b;
>      int [] numbers;
> }
> void main() {
>      import std.stdio;
>      int a = 300;
>      const numbers = new int[2];
>      const c = const(AB)(a, 20, numbers);
>      writeln(c);
> }
>
> Bye,
> bearophile

auto c = AB(a, 20, numbers)         <=>   AB c = {a, 20, numbers};

auto c = const(AB)(a, 20, numbers)  <=>   const AB c = {a, 20, numbers};
April 16, 2012
Timon Gehr:

> auto c = AB(a, 20, numbers)         <=>   AB c = {a, 20, numbers};
> 
> auto c = const(AB)(a, 20, numbers)  <=>   const AB c = {a, 20, numbers};

I think your second equivalence is wrong:
const c = AB(a, 20, numbers)  <=>   const AB c = {a, 20, numbers};

Bye,
bearophile
April 16, 2012
On 04/16/2012 11:43 PM, bearophile wrote:
> Timon Gehr:
>
>> auto c = AB(a, 20, numbers)<=>    AB c = {a, 20, numbers};
>>
>> auto c = const(AB)(a, 20, numbers)<=>    const AB c = {a, 20, numbers};
>
> I think your second equivalence is wrong:
> const c = AB(a, 20, numbers)<=>    const AB c = {a, 20, numbers};
>
> Bye,
> bearophile

This is what DMD currently does. This behavior does not make any sense.
April 17, 2012
On Monday, 16 April 2012 at 14:50:43 UTC, sclytrack wrote:
>
> struct AB
> {
> 	int a;
> 	int b;
> 	int [] numbers;
> }
>
> int main()
> {
> 	int a = 300;
> 	const int [] numbers = new int[2];
> 	const AB c = {a,20, numbers};		// line 66
>     writeln(c);
> 	return 0;
> }
>
> ----------------------------
> -debug
> -unittest
>
> src/main.d(66): Error: cannot implicitly convert expression (numbers) of type const(int[]) to int[]
>
> ---------------------------
>
>
> const AB c;
>
> 	typeof(c.a)	is  const(int);
> 	typeof(c.numbers) is const(int []);
>
>
> Shouldn't the code above accept the const(int [])   ?

Should do. It is a compiler bug.

I've filed this issue in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=7929

And posted a pull request to fix compiler code:
https://github.com/D-Programming-Language/dmd/pull/884

Thanks.

Kenji Hara
April 22, 2012
On 04/16/2012 09:27 PM, sclytrack wrote:
> On 04/16/2012 08:15 PM, sclytrack wrote:
>>
>>> const numbers = new int[2];
>>> const c = const(AB)(a, 20, numbers);
>>> writeln(c);
>>> }
>>>
>>> Bye,
>>> bearophile
>>
>> That's exactly what I needed, thanks.
>
> Seems to be forwarded to the constructor if there is one.
>
>
> (untested code)
>
> struct B
> {
> int [] _list;
>
> this( const int [] list) const
> {
> _list = list;
> //typeof(_list)=int []
> //typeof(list) =const(int[])
>
> }
> }
>
>
>
> Because of the const on the back of the constructor.
> Normally the typeof(_list) should be const(int[])
> but assignable once, because we are in the constructor.
>




this() const
{
	_a = 10;
	_a++;		//This is wrong. ??
}

with _a a private variable. The _a++ is going to be incorrect in the future right?





Below is me talking nonsense ignore it.
>
> But a mutable design has been chosen (_list is int [])
> until it is baked or cooked
> or whatever the terminology. (don't have Andrei's book)
> Probably for flexibility. Are there people out there
> using this flexibility?
>
> Just pondering,
>
> Sclytrack

Top | Discussion index | About this forum | D home