hashmap data can't migrate from compiletime to runtime

[taoria]

package testcom
import HashMap
HashMap<int,int> test_map= compiletime(new HashMap<int,int>())
@compiletime function initMap()
    test_map.put(1,10)
init
    Log.info(test_map.size().toString())
    Log.info(test_map.get(1).toString())

should get

1
10

but get

1
0

is there something i did wrong?

[peq]

Hmm, I think this happens because HashMap uses a static field for the hashtable and since this is not marked as compiletime it will have different values at runtime and compiletime.

@Frotty Maybe this field should be initialized with a compiletime expression in StdLib?

[Frotty]

I suppose it could be done. If this is no longer a super-experimental feature we should probably also document it.

[Frotty]

fixed by https://github.com/wurstscript/WurstStdlib2/commit/0cd75387f2b50bb89057fbf78f61d84cf4885beb

[Frotty]

@peq That didn't solve the issue. This simple example still doesn't work.

[taoria]

Emmm,I find expression ‘sth castTo int’ has different result on runtime and compiletime.this is the reason why compiletime migration failed on hashtable-based data structure.

import HashList
HashList<int> hashList = compiletime(new HashList<int>())
int i = compiletime(initMap())
function initMap() returns int
    hashList.add(10)
    return hashList castTo int
init
//force hashlist.ht to be public and make the initializing compiletime 
    Log.info(HashList.ht.loadInt(i, 0).toString())

get 10.（：

[peq]

Hmm, I don't think it makes sense to keep the object ids the same in compiletime and runtime. If there were 1000 HashList items created at compiletime but only id 1 and 1000 migrated to runtime, then we would have to initialize the free-list for the remaining 998 items at map loadtime.

It's probably better to just work around this limitation and don't rely on casting to int.

[taoria]

looks like it's not a wurstscript issue anymore?and yes it's easy to make a compiletime compatible and hashtable based container.🙂

[peq]

It's still open for discussion.

On the one hand the feature would be easier to use if object ids stayed the same.

On the other hand it makes the compiler more complicated and the generated map script bigger.