Hacker News new | past | comments | ask | show | jobs | submit login

> I also would guess that the compiler elides the Badge argument since it is never used.

It's also zero width, so no temporaries, etc.




Problem is, nothing elides the presence of these obtrusive badge parameters in the source code.

A few bytes of stack is the least of my concerns on some file system device registration function that is called five times when the system boots.

If we imagine a software organization "going to town" with this badge approach so that there are badges all over the code base, it's not hard to imagine how it would be a nuisance.


Depending on how you approach it (eg if you don’t instantiate it as {} but instead something like access::device, which is a type alias for Badge<Device>) then I find being explicit about access rights is quite helpful sometimes. In this case, I probably would avoid it too in favour of private headers, but then, I prefer freestanding namespaces functions over objects when possible anyway (too much functional programming maybe), so I’d partition my API that way instead.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: