Make concatenate operator ".." work on tables

Feature Requests Studio Features
#50

Even if it did, it’d pretty much be the same behavior is JSONEncode and not help in OP’s case (but the feature on the Trello card would)

#51

still support
I’m against modifying Lua’s internals. I want it to stay vanilla. Library modifications are fine though as they are like addons.

2 Likes
#52

If you are going through with this, then it would be nice to make it work properly for all types (except userdata) that cannot be properly concatenated yet: tables, bools, and nil (“Test” … nil fails for similar reasons, could be stringified to “nil” by …).

#53

still no support

stringify is a pointless name change that can already be accomplished with existing methods.


[quote="sparker22, post:51, topic:24789"] I'm against modifying Lua's internals. [/quote] That's interesting, considering you were in favor of modifying "table" to add stringify.
#54

I didn’t know print() could take a variable number of arguments.

If typing “print(” offered some form of autocomplete then I would have known that was the way to do it in Lua.

#55

But we had a discussion just the other day that print does take a tuple, so you should have known by now… :sweat_smile:

#56

table is a library though which I said is fine.[quote=“sparker22, post:51, topic:24789”]
Library modifications are fine though as they are like addons.
[/quote]

I don’t really care as long as the internals aren’t touched outside of library additions.

#57

Context help will tell you this if you highlight ‘print’ in a script. Alternatively, it’s also on the wiki. That being said, Intellisense is a work in progress.

#58

Yes as you can see, getting debug output is a real pain point for me.

#59

Still it’s kind of odd that we have to invoke HttpService to turn a table into a string though? Like if I’m just printing output, it’s weird to see HttpService there even though I’m doing nothing network-related. And if the concatenate operator will be able to do this, we’d still need to say something like

someString = "" .. someTable

If we really don’t want to use HttpService. If we had a method in the table library that would stringify tables in the same way as the concatenate operator will (if this goes through at least), then we won’t need to do any ugly things with HttpService or the line I just put.

EDIT: thinking about it, if this change is made then probably tostring will have to be changed so that it properly prints tables. So this may not be relevant then anymore.

#60

I just want my code to look elegant and understandable.

Lua code tends to look like barf.

#61

I don’t agree with that. I think if done properly it looks good.

#62

I’ve been thinking about it since my posts yesterday, I was a bit hesitant at first because it’s quite a basic Lua operator that you want to change the behaviour of, but it will probably be beneficial and won’t break existing code. So I’m in favour of the change now.

If this is happening though, I would really like if this were the case (as I mentioned):

  • Apply it to all types that cannot currently be concatenated properly, not just to table (table, nil, booleans, userdata (if a tostring method is available for it))
  • Make tostring print tables in the same way as they are concatenated, so we don’t need to use HttpService anymore if we just want to catch the stringified table into a variable. HttpService:JSONEncode(someTable) looks less clean than tostring(someTable), especially in code that doesn’t even have any networking.
#63

This shouldn’t happen because there’s literally no good default way to turn a table into a string. Concat is too canonical; it says “this is the correct format in which a table is converted to a string and any other format is wrong”.

I’d be all for a stringify-like function, because you’d at least be able to supply arguments to change how the result is formatted.

5 Likes
#64

But do you see any issue in having both? If you just concatenate, it would pick a default format, and you can always serialize it in a different way by manually turning it into a string using that function (with different parameters).

i.e.

local t = {a = 1, b = 2, c = 3}

local s1 = "Table: " .. t
-- Some default format, say: 'Table: {a = 1, b = 2, c = 3}'

local s2 = "Table: " .. table.tostring(t, "json")
-- 'Table: {"a":1,"b":2,"c":3}'

(Function name and parameters are pseudo, just to give an idea)

1 Like
#65

I only have an issue with concat, for the reasons already mentioned. A function is fine because it’s not built into the language.

Also note when I say “format”, I mean things like how keys are printed and how loops are handled and whether the result follows any particular syntax. There’s a million and a half ways to handle these.

3 Likes
#66

The most useful solution would be to add a ‘table explorer’ feature to the output window.

So you get
blah blah: table: asdfg
from some print statement

Then you click the table ID to open some explorer window which lists all the key-value pairs (and you can then do this recursively if any keys/values are tables).

Then it would also work for tables bigger than a few values, and there wouldnt be confusion about how to “stringify” it because it never is (only the contained data is, like now).

1 Like
#67

The default behavior of “…” would be a somewhat big thing to change. Not in terms of being a practical problem, but in deviating from standard Lua when other solutions are possible.

Why not use print’s ability to autmoatically tostring and concat things?

> print("game pad:", game:GetService("UserInputService").GamepadEnabled) game pad: false

> print("Bool:", true, " Num:", 9.4, " Nil:", nil, " Workspace:", workspace) Bool: true Num: 9.4 Nil: nil Workspace: Workspace

I think a way to represent tables as a string for debugging purposes would be very useful, and including it as a default only extends that use. Replacing standard behavior such as concat’s isn’t needed for that purpose, though.

Here’s the approach I would take:

  1. Add a method to turn a table into a string. Perhaps table.tostring, or maybe a different name that makes it clear that the format is arbitrary.
  2. Either modify the print method, or add a new one. This method would concat all arguments together (like print), tostring-ing non-tables and table.tostring-ing tables.

My reasons for this are:

  • Doesn’t replace standard Lua behavior.
  • This avoids controversy.
  • The standard behavior serves to make whatever a piece of code does very clear. Automatically tostring-ing when concatenating could arguably change that.
  • Does not affect existing code. I’m sure someone has written something that depends on tostring returning table: ########, even if one may consider it badly made to do such a thing.
  • Personally, I have used the standard Lua behavior to check if two tables in completely different sections of a program (such that I can’t easily use ==) are the same. If this new behavior replaced the old behavior then it would become more difficult, especially if the tables were copies of each other or if they held the same data.
  • A new method could be made specifically for debug messages. The functionality of this method could be extended later in some way without affecting existing code that just wants to print to the output and not have any further purpose. For example, the ‘table explorer’ functionality could be added to this new method.

As a last thing, I’d like to note that I personally feel concat should apply just to strings for the default types. I, personally, do not like that it works with numbers. If I want something to be a string I use tostring or I use a method that does tostring automatically, like print.

2 Likes
#68

Best would be having table.tostring indeed.
Then you can just wrap tostring to use table.tostring for tables.
print/warn use tostring() to convert non-strings to strings, for cases like this.

1 Like
#69

I think my opinion will be very simply that … could be confusing.

What if I did tab1 … tab2, I assume I get a string but a new player might think it joins the two tables into one.

2 Likes