I've noticed that I can use int like a constructor, as in:
    int x = int(1);
but I can't do the same thing with slices
    int[] y = int[]([1, 2]);

Is there something I'm missing here or is this a potential enhancement? It can make some types of generic code a little more annoying.

On Tuesday, December 4, 2018 3:17:04 PM MST jmh530 via Digitalmars-d-learn wrote:
> I've noticed that I can use int like a constructor, as in:
>      int x = int(1);
> but I can't do the same thing with slices
>      int[] y = int[]([1, 2]);
>
> Is there something I'm missing here or is this a potential enhancement? It can make some types of generic code a little more annoying.

Using parens with dynamic arrays already has a different meaning. It's how you provide the size of the dynamic array. e.g.

auto x = int[](12);

or

auto x = int[][](3, 4);

In the first level, you can put the number in between the brackets instead - e.g.

auto x = int[12];

but that falls apart at deeper levels, because the number in between the brackets would then mean a static array (making it so that you have a dynamic array of a static array). So, in the general case, parens are how you provide a dynamic array's length. This was true long before it became possible to use parens for construction with built-in types like you do with user-defined types.

- Jonathan M Davis

On Tue, Dec 04, 2018 at 10:17:04PM +0000, jmh530 via Digitalmars-d-learn wrote:
> I've noticed that I can use int like a constructor, as in:
>     int x = int(1);
> but I can't do the same thing with slices
>     int[] y = int[]([1, 2]);
> 
> Is there something I'm missing here or is this a potential enhancement? It can make some types of generic code a little more annoying.

For built-in types, you can just write:

	int[] y = cast(int[]) [ 1, 2 ];

Well OK, for int[] it's kinda silly 'cos that's the default, but in my code I've often had to write things like:

	auto z = cast(float[]) [ 1.0, 2.0, 3.0 ];

because otherwise it would be inferred as double[].

But yeah, this wouldn't work so well in generic code where you might be constructing a user-defined type.  What Andrei said about people not wanting built-in types to behave differently from user-defined types holds true here.  In an ideal language, there would be no lexical distinction between the two, and generic code would Just Work(tm).  D is a lot closer to this ideal than many other languages, I daresay even the majority of languages, but alas, it's not completely there.


T

-- 
Without geometry, life would be pointless. -- VS

On Tuesday, 4 December 2018 at 22:35:48 UTC, Jonathan M Davis wrote:
> On Tuesday, December 4, 2018 3:17:04 PM MST jmh530 via Digitalmars-d-learn wrote:
>> I've noticed that I can use int like a constructor, as in:
>>      int x = int(1);
>> but I can't do the same thing with slices
>>      int[] y = int[]([1, 2]);
>>
>> Is there something I'm missing here or is this a potential enhancement? It can make some types of generic code a little more annoying.
>
> Using parens with dynamic arrays already has a different meaning. It's how you provide the size of the dynamic array. e.g.
> [snip]

I don't think I either knew or had remembered this, thanks.

On Tuesday, 4 December 2018 at 23:28:42 UTC, H. S. Teoh wrote:

> Well OK, for int[] it's kinda silly 'cos that's the default, but in my code I've often had to write things like:
>
> 	auto z = cast(float[]) [ 1.0, 2.0, 3.0 ];

Err,

auto z = [ 1.0f, 2, 3 ];

?

On 12/5/18 5:34 AM, Stanislav Blinov wrote:
> On Tuesday, 4 December 2018 at 23:28:42 UTC, H. S. Teoh wrote:
> 
>> Well OK, for int[] it's kinda silly 'cos that's the default, but in my code I've often had to write things like:
>>
>>     auto z = cast(float[]) [ 1.0, 2.0, 3.0 ];
> 
> Err,
> 
> auto z = [ 1.0f, 2, 3 ];
> 
> ?

But that's only because 2 promotes to float. If it's 2.0 (or let's make it 2.1 so you can't have the int cop-out), then you have to tag all the elements (a bit annoying).

However, you can also do

float[] z = [1.0, 2.0, 3.0];

which is what I'd prefer, and isn't as verbose as either the cast or the OP's suggestion. But in cases where you aren't assigning a variable, float[](1.0, 2.1, 3.5) would be more desirable than casting (since casting is dangerous).

I would say we should allow such usage. And it doesn't conflict with array multi-dimensional allocation, since that accepts not a literal, but an argument list of sizes.

-Steve

On 12/5/18 12:00 PM, Steven Schveighoffer wrote:
> But in cases where you aren't assigning a variable, float[](1.0, 2.1, 3.5) would be more desirable than casting (since casting is dangerous).

Sorry, I meant float[]([1.0, 2.1, 3.5])

-Steve