the `==` operators in the prototype that take `object?` only check for null
the
==object?
Pwe have an
object?actually yeah that operator is never going to get called because it's already impossible to compare a ptr to be
null
Mso that'll check a null object but not a null pointer wrapped in an object
Pthat's why
nullptrthis seems like intended behavior, no need to special case nint/nuint
Ma nuint is not necessarily a pointer
Mit is simply
Ma native sized integer
Pyeah unless we're adding nint and nuint operators, which aren't in the proposal atm, there's no boxed thing we could possibly compare against
Pa developer would have to explicitly write
if (ptr == (object?)null)which is much more work than writing
if (ptr == nullptr)
Pwe have multiple operators that take objects e.g. arrays
Moh right
Myeah fair
Pthe compiler won't be able to resolve which you're triyng to pass
nullbetter idea
Mimplicit cast to bool
Mif (ptr)
Munity does it
Pnot a bad idea
PC does it as well technically
Cyep, you are right, and I knew that because we talked about the nullptr thing already
MC doesn't have booleans, exit your mind from such high level concepts
Meverything is an integer
Pyeah i KNOW maxine
Mstruct? lots of integers
MIT'S ALL INTEGERS PERKSEY
Pas much as
stdbool
Ai am slightly concerned that this is becoming too far away from the language's design
remember - most people (myself included) aren't gonna want to learn and use a bunch of custom types that aren't language constructs that do basically the same thing
remember - most people (myself included) aren't gonna want to learn and use a bunch of custom types that aren't language constructs that do basically the same thing
P
Pthen just pretend they're all unmanaged pointers...
Pthe only place where it'll hurt is return typing
Peverywhere else it's basically just designed to be equivalent to what we have in Silk.NET today where you can pass in whatever, just without millions of overloads
Ai'm trying to think from the perspective of a relative newb
where they will be used to arrays or maybe spans
you can teach them what a pointer is and how its worked, but give them
i can certainly say that I stopped being able to wrap my head around the pointer structs as soon as it got beyond
where
where they will be used to arrays or maybe spans
you can teach them what a pointer is and how its worked, but give them
PtrMutPtri can certainly say that I stopped being able to wrap my head around the pointer structs as soon as it got beyond
Ptr<T>where
Ptr<T>yes but you can't do that because it's a ref struct
Punless we want to discard strong typing entirely
Pwhich... we can do but it feels wrong
Pand prone to misuse
Pmore prone to misuse than if our users just read the docs
Ait's a library binding to opengl and other low level libraries
they're the misuse capitals of programming
i think trying to go this far to prevent misuse is a bit of a waste of time, people will misuse it regardless
they're the misuse capitals of programming
i think trying to go this far to prevent misuse is a bit of a waste of time, people will misuse it regardless
Ai misuse the entirety of C# so
Aif there's a will there's a way
Cand what happens when they see byte**const (which I don't know if C# can even replicate with base keywords)?
Pyeah C# can't replicate it, it's just all
byte**i'll write some words on the proposals, but it's best to stick with this for now. we could go with an analyser based approach and go with stuff as you suggest, but this does still lose type safety a lot.
Pi feel like generalising any pointer to a single type (or single generic type) is extremely dangerous and becomes even more so when you start thinking about structs, which we haven't tackled yet
Aunsafeif the user fucks it up, it should be because of something they did
not because the library provided a billion custom pointer types that caused the user to use the wrong one
i'm assuming this whole thing is so that silk can be used in a "safe" environment, which is fair enough, but there's only so safe you can get with opengl and other lower level libraries
try to make it too safe and you enter rust territory, and i don't think anyone really wants that
if you take a look at opentk, its still in a safe context but you can very easily screw it up just like anything else
Pyou have a fence around your garden, right? people can just climb over that, stand on it, do unspeakable things to it, whatever. is this an argument for not having a fence at all?
Ano, but you could make the argument that it's pointless making the fence too tall. sure it makes it harder to climb over, but it also makes things worse for you as well