PureBasic Forums - English

Does anyone know when this syntax became disallowed, which now fails the syntax check on compilation? I tried PB 6.20 Windows 64-bit today and found that I needed to assign a dummy value to each new map element, although I only need the key, for this particular app.

At least one element is required and must be initialized, depending on your Map type, if you do it this way

Or else, you have to do it with AddMapElement, it's safer

This change was made in 6.00, I believe beta 5. I'd have to go dig up the forum thread again, but if you find it, do a search for "passive syntax" I believe and you'll find it. I am not a fan of this change personally as I've stated before, I think that simply attempting to access a key shouldn't create it...talk about typo bugs...
I did once propose having this controlled with EnableExplicit/DisableExplicit, but that went nowhere

ChrisR wrote: Wed Dec 18, 2024 4:42 pm At least one element is required and must be initialized, depending on your Map type, if you do it this way

Code: Select all

NewMap  RecList()
RecList("Record-1") = 1 ;or = 0

The above is preferred, assigning zero to the smallest possible variable, as we don't need to store anything except a map key.

Why does PB now require a value, whereas for PB 6.00 it didn't? Just a bit surprised really.

Quin wrote: Wed Dec 18, 2024 5:03 pm This change was made in 6.00, I believe beta 5. I'd have to go dig up the forum thread again, but if you find it, do a search for "passive syntax" I believe and you'll find it. I am not a fan of this change personally as I've stated before, I think that simply attempting to access a key shouldn't create it...talk about typo bugs...

I remember you've mentioned this recently Quin, yes.

It's not this aspect that I'm referring to. I currently run PB 6.00 LTS Windows x64 and my example compiles fine.

PB 6.20 Beta will not compile it. It gives a syntax error. I suppose I hadn't expected that a new version of PB would break my code

Implies that an integer value is used for each entry.

Maybe
can save you memory.

Interesting, I figured the change was supposed to solve the complains about keys being created randomly by if statements.
this still works with 6.12LTS x64:
I guess it's because the IF statement is evaluating the result of each OR the key is created

Norm.

There is always an associated value to a map element, this change was made to avoid error, now it's more explicit that you create an element.

infratec wrote: Wed Dec 18, 2024 6:07 pm

Code: Select all

NewMap  RecList()

Implies that an integer value is used for each entry.

Maybe

Code: Select all

NewMap  RecList.a()

can save you memory.

Actually, my original code used RecList.s() and since changing it to RecList.a() I've improved typical performance by 100ms

Fred wrote: Wed Dec 18, 2024 6:35 pm There is always an associated value to a map element, this change was made to avoid error, now it's more explicit that you create an element.

It's a pity that the change prevents existing code from compiling.

Sometimes maps are very useful as a form of key list, but with the benefit of lookup, and hence without need of associated values.

Well it was changed because someone complained he got a bug unnoticed due to a lazy notation. And now you are complaining because you miss the lazy notation (which is not that obvious TBH). So yes we need to make choice and the code change to adapt is very small. As said before, a Map always hold a value, it's not an HashSet, so it's made explicit.

Fred wrote: Thu Dec 19, 2024 6:01 pm As said before, a Map always hold a value, it's not an HashSet, so it's made explicit.

I understand now — the change was about the notation, rather than avoiding the need for an associated value. The ideal for me, would be to provide the ability to not store an associated value, but that's not possible, I can see that now. No worries.