add primitive refs package

[Cokemonkey11]

No description provided.

[rhazarian]

Hey, was just looking through PRs and noticed this one.

This will be really useful, but you can do it much simpler and more universally, like this:

public class Ref<T:>
    T val

    construct(T val)
        this.val = val

With the "new generics" (T:) there will be no convertation overhead and it will be available for all types.
I'm using a class like this in my projects and wanted to make a PR with this but could not find time :D

[Frotty]

With new generics this shouldn't be needed most of the time - maybe add description and use case. Doesn't rly seem like stdlib material.

[Cokemonkey11]

there will be no convertation overhead

this shouldn't be needed most of the time

@Frotty can you clarify this a little more? Are "new generics" already a thing? In used in the stdlib? documented in the manual?

"Will be", "shouldn't", "needed", "most of the time" - so, is it useful or not?

[GetLocalPlayer]

With new generics this shouldn't be needed most of the time

What is "new generics"? Where can I learn it?

Doesn't rly seem like stdlib material.

Doesn't it solve the variable capturing problem with closures? Would be great if wurst compiler did that work implicitly.

[Frotty]

@Frotty can you clarify this a little more? Are "new generics" already a thing? In used in the stdlib? documented in the manual?

What is "new generics"? Where can I learn it?

Perhaps in the ticket with the same name wurstscript/WurstScript#679

"Will be", "shouldn't", "needed", "most of the time" - so, is it useful or not?

How about you tell me - with a description?
It seems very limited in use - as @rhazarian suggested it should just be a Reference<T:> class and perhaps something that would be an equivalent to Java's AtomicInteger.
In many cases you should use make a package specific data class though, for reasons stated before (type safety, encapsulation, smaller dispatch).

Doesn't it solve the variable capturing problem with closures? Would be great if wurst compiler did that work implicitly.

There is no problem, so I'm not sure what you are referring to. Primitives are call by value and objects call by reference, just like primitives and handles in Jass. With this PR you could use a Reference I guess.

[Cokemonkey11]

Hey @Frotty

Perhaps in the ticket with the same name wurstscript/WurstScript#679

From looking at this ticket it's not quite clear what already works/doesn't work, or what is stable/unstable. Is the <T:> syntax already the right thing to use? From a quick search through EBR for example, I don't see it in use.

How about you tell me - with a description?

It is specifically for use where allocation is needed for primitives. In Bastards and Conquerors, for example, I use it for both bool and real.

There is no problem, so I'm not sure what you are referring to. Primitives are call by value and objects call by reference, just like primitives and handles in Jass. With this PR you could use a Reference I guess.

I agree that it's not a "problem" as such, but that is at least one of the use cases I had intended - example.

[Frotty]

From looking at this ticket it's not quite clear what already works/doesn't work, or what is stable/unstable. Is the <T:> syntax already the right thing to use? From a quick search through EBR for example, I don't see it in use.

Only 1. - that is the point. The colon syntax already works, it is already used in the stdlib, I didn't make any mention about stability. Not sure what EBR has to do with this, it doesn't even use any generics outside of stdlib.

It is specifically for use where allocation is needed for primitives. In Bastards and Conquerors, for example, I use it for both bool and real.

Your examples aren't nested, a simple global would suffice. If it were nested, a stack like it is done in the stdlib seems fine in library use.

I agree that it's not a "problem" as such, but that is at least one of the use cases I had intended - example.

So will you update the PR ?