when I say WIP, I very much mean that! The code samples are bad, theres a grand total of two things in the stdlib, its missing EBNF syntaxes and most things (e.g. generics) are just simple "first drafts" that could change a lot!
live gnome reactionso what on earth is even going on atp
why can't they just say "our fault, we fucked up" and also give nirbheek (I don't know his name, just using his username) the boot.
You can't pride yourself on supporting diversity if you don't even enforce your bloody CoC for crying out loud. Mum's ain't the word here, you gotta handle that shit before more people leave. Hell, even Kolunmi (creator of Bazaar (flatpak app store)) said "... this official post as written on behalf of the foundation has made every ounce of desire to participate in this project completely leave my body." Bleeding valuable contributors for what gain?
I don't like GNOME but I'd hate to see it die or worsen.
c++ redo project: class nonsensethey're making me do traits
interface IWindow {
bool maximise() unimplemented;
std::string getWindowName() { return windowName; }
bool setWindowName(std::string newName) unimplemented;
// Private in this system is the equivalent of `protected` in C++
private:
// I would imagine this would be beneficial? But I know that Rust doesn't allow this...
std::string windowName;
}
class SDLWindow implements IWindow {
constructor(std::string winName, Vector2i size, int flags) {
win = SDL_CreateWindow(winName.c_str(), size.x, size.y, flags);
windowName = winName;
}
destructor() {
SDL_DestroyWindow(win);
}
bool maximise() {
return SDL_MaximiseWindow(win);
}
bool setWindowName(std::string newName) {
bool success = SDL_SetWindowName(newName);
if (success)
windowName = newName;
return success;
}
private:
SDL_Window* win;
};
// Error in trait style: can't extend classes, only interfaces
class SDLWindowWithRenderer implements SDLWindow {};
// Presume IPrintable is provided by your code but SDLWindow is an external dep in this scenario
implement IPrintable for SDLWindow {
std::string toString() { ... }
};
get checks based on a given lobby's progress (example: lobby A getting 10% total checks sends Jellyfish to a Celeste player in lobby B, which then makes lobby B get 10% total checks, sending a recipe to a minecraft player in lobby A)
@freyalikesgirls Yeah but I mean more from both a compiler perspective (do we just presume everything in an interface is "pure" until we get an impl? How does that work for shared libraries?) and from a developer using a library's perspective (how do I know which function has a default implementation and which doesn't?)
@freyalikesgirls Oh yeah, good point. Given I already want to add the and and or keywords (just to make it slightly clearer when you're working with the & (AND) and | (OR) operators but also just for better readability in general), I could probably put interfaces into my language (even though in my blog, I said I wouldn't).
I'm wondering how I'd be able to cleanly communicate whether an interface's function is "pure" or not.
interface Drawable {
void draw() pure; // Something like this instead of `= 0;` ?
};
@freyalikesgirls is there a reason multi-impl inheritance is stinky? Since C++ interop isn't actually set in stone (to enable breaking changes since only C interop is wanted, given its, well, a C superset but not a C++ superset. But C++ interop might be cool later on for extra library choices for devs), I can pretty much replace/alter as much of it as possible to make it better.
I'm just personally neutral on multi-impl inheritance as I think it can be good if you like to split things up more (e.g. class Entity : Collidable, Drawable where Collidable is something within a 2D worldspace and Drawable is something capable of being drawn using OpenGL. An invisible wall would only need Collidable, a GUI element only needs Drawable and potentially a different thingymajig if it needs mouse input support, e.t.c.) but I'm open to changing it
Also, I'd need elaboration on pure virt base classes being gross too (as to me, I've not noticed anything being wrong or bad but thats mostly because I've not used it too much (all of my virtual base classes have some sort of implementation in them, usually due to having some behaviour that all derivs would need anyways)).
Wanna just deal with getting C stuff working first in my compiler (maybe also making functional IR?)
Applying things I like from other languages (e.g. Rust's enum unions and error handling (option and result, instead of C++ awful exception model), maybe Carbon's generics system?)