Modify

Opened 10 years ago

Closed 10 years ago

#2548 closed Feature Request (Rejected)

Array Literal Notation

Reported by: Tasiro Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:

Description

Please allow the use of the array literal notation as an expression and not only as an array initializer.
Example:

Local $data [2] = ["a", "b"]
; ...
_ArrayConcatenate ($data, ["c", "d"])

Attachments (0)

Change History (7)

comment:1 Changed 10 years ago by Mat

Originally requested as part of ticket #2029 (see the anonymous comment and it's rejection by a developer at the time.

Currently covered by another open ticket #2505, I'm going to bend the rules slightly and close the other ticket as a duplicate of this one (don't shoot me guys) as this ticket is better.

To reiterate, no current developer (Jon) has rejected the idea yet, so it's not my place to close it, but it has been rejected in the past.

comment:2 Changed 10 years ago by Tasiro

The last example in #2505 requires access to subarrays of multidimensional arrays, too.

Anonymous's suggestion is bad from several aspects one of which is creating exception of rules.

Oh, I didn't see that.
Why is it a bad suggestion? What is the difference between strings and arrays? Strings get copied - arrays get copied. Only the operations are different. I can create temporary strings, but not temporary arrays. Isn't that an exception? Why do I have to use something like array(1,2,...,15,more(16,17)) instead of [1,2,...,16,17]?

Another solution mgiht be variable length argument lists:

Func array (...$arguments) ; ES6 rest parameters
    Return $arguments
End Func

comment:3 follow-up: Changed 10 years ago by Mat

Varargs is also a request I made a while ago, #2278.

Several problems with what you are saying: Firstly strings cannot be considered anything like arrays in AutoIt. Even if you do, you should consider the fact that they are read only so creating a temporary string has non of the issues Valik was talking about in #2029.

Secondly, the problem is not in simple use like you are looking at, its in the edge cases:

For a start, what kind of array would [[5, 6], [7, 8]] be? With current syntax I'd expect that to be a 2x2 array, but with literal arrays it would be a 2 element array, with nested arrays.

comment:4 in reply to: ↑ 3 Changed 10 years ago by Tasiro

Several problems with what you are saying: Firstly strings cannot be considered anything like arrays in AutoIt. Even if you do, you should consider the fact that they are read only so creating a temporary string has non of the issues Valik was talking about in #2029.

Strings are a fundamental data type in AutoIt 3, numbers and arrays too. Strings have a special syntax to describe them, numbers too. Arrays haven't.

For a start, what kind of array would [[5, 6], [7, 8]] be? With current syntax I'd expect that to be a 2x2 array, but with literal arrays it would be a 2 element array, with nested arrays.

That's a parsing problem. a[0][1] (with a=[[2,3],4]) should be:

      []
     /  \
   []    num
  /  \    |
id   num  1
 |    |
 a    0

But it is (only guessing):

   []
  /  \
id  []-list
 |   |   |
 a  num num
     |   |
     0   1

(At least it is treated that way.)
Are you using an LL parser tool? If not, you could remove that restriction.
Why not make every array with more than one dimension an array with nested arrays?

comment:5 follow-up: Changed 10 years ago by Mat

When did I talk about implementation issues? It's not a parser issue, it's a language issue.

The only thing in your comment that makes sense is asking why don't we make all multi-dimensional arrays nested. Even that doesn't really make sense:

How about ReDim and UBound, how would they work? What about the performance of multi-dimensional arrays? It's not even possible to access nested arrays yet in AutoIt either. Users would have to add extra error checking for every element in a nested array if they wanted to make sure all the sub-arrays have the same length...

Please, think about what you are asking. You make things sound very trivial when the change would break every AutoIt script using 2d arrays. Even the standard Array.au3 udf would be broken.

comment:6 in reply to: ↑ 5 Changed 10 years ago by Tasiro

When did I talk about implementation issues? It's not a parser issue, it's a language issue.

The language described by the syntax is the same.

For a start, what kind of array would [[5, 6], [7, 8]] be? With current syntax I'd expect that to be a 2x2 array, but with literal arrays it would be a 2 element array, with nested arrays.

The interpreter complains, if I try to execute Local $a=[1,[2]]. Would your example really become an array with nested arrays?

[...] why don't we make all multi-dimensional arrays nested.

You could treat them that way.

Let a be an array with m dimensions and b a subarray of a with n dimensions.

How about ReDim and UBound, how would they work?

Why should ReDim change its behavior? It would throw, if any b was passed to it.
UBound(b,0) should return m. UBound(b,d) should return UBound(a,d+m-n).

What about the performance of multi-dimensional arrays?

Why should it change? Your multi-dimensional arrays only consist of pointers, right? You would only need some kind of view object.

It's not even possible to access nested arrays yet in AutoIt either. Users would have to add extra error checking for every element in a nested array if they wanted to make sure all the sub-arrays have the same length...

No, it is your own fault, if you pass an argument of the wrong type. It is possible, but it is wrong.
It is not even necessary to allow access to nested arrays...

You make things sound very trivial

Of course, would you make your feature requests sound complicated?

the change would break every AutoIt script using 2d arrays. Even the standard Array.au3 udf would be broken.

Really?

comment:7 Changed 10 years ago by Melba23

  • Resolution set to Rejected
  • Status changed from new to closed

Rejected.

M23

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.