a developer would have to explicitly write `if (ptr == (object?)null)` to make the compiler happy
a developer would have to explicitly write
if (ptr == (object?)null) to make the compiler happy
Pwhich 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
null intoMbetter 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 pretends otherwise
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
PtrMutPtr or what have you? i'm not so surei can certainly say that I stopped being able to wrap my head around the pointer structs as soon as it got beyond
Ptr<T>, which on a personal level is all that I think is neededwhere
Ptr<T> is a high level pointer to just stuffPyes 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** which the user can do whatever they please withPi'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
Aunsafe in C# is by its very nature "extremely dangerous"if 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
Ai think having some levels of type safety is good, just not a massive wall of custom types for the name of absolute type safety
Pi think as i said on the coffee & code this needs to be discussed in a formal working group meeting once we have something to discuss
Kalso this is at least partially to help cut down on overload count separate from the safety issue
Kprovides implicit conversions you can use instead of having a silly number of overloads
Pyeah that's the sole goal
Pwe could also just go fully unsafe but have extension methods generated on-the-fly to do marshalling and the IDE experience would be even more terrible than this
Cyes, D2D in specific has a 16 ptr overload that could take spans for each, 16^16 is stupid
Pultimately these days in the advent of TerraFX being an official DNF project Silk.NET has no reason to exist other than its overloading abilities, and the current implementation of this is known-problematic which is why we're trying to come up with another one which is less problematic. still problematic mind, but a less so in that you don't have to sift through hundreds of overloads.
Aif that's the case, could it be worth considering switching to a more safe/managed environment? instead of trying to get both safe and unsafe at once
there are no (sane) safe vulkan libraries for example, silk could fill that gap quite easily if tried
and by safe i don't mean arrays etc, i mean spans
there are no (sane) safe vulkan libraries for example, silk could fill that gap quite easily if tried
and by safe i don't mean arrays etc, i mean spans
Pbut then you can't mix and match which was the reason our overloading system was so great