<marler8997>
with status quo, could you implement this by creating a function that implements Allocator.get?
<marler8997>
so this features allows you to implement this Interface function that takes a struct and returns another struct?
<marler8997>
oh? will read
<marler8997>
ikskuh, have you asked yourself this question? "Can the language do without this feature"?
<marler8997>
ikskuh, your'e saying not passing TypeInfo but the sub union types of TypeInfo?
<TheLemonMan>
marler8997, I take my shitposting seriously
<marler8997>
TheLemonMan = TheTrollMan
<marler8997>
omg lol!!!!
<marler8997>
but seriously no I don't know the reference :( Are you sure 32 is old enough to know what? How old are you?
<marler8997>
don't being that madman into this
<marler8997>
jesus Stallman
<TheLemonMan>
marler8997, I was mocking Stallman's famous phrase :(
<marler8997>
ok TheLemonMan, I wanna hear your take on it
<marler8997>
another opponent steps into the ring
<marler8997>
someon is wrong on the internet and I can't abide!!!
<marler8997>
ikskuh, I'm picturing you barging into CppCon and when the speaker says their function is a zero cost abstraction you saying "That's not what you mean by Zero Cost Abstraction"....
<marler8997>
like 3 hours apparently!!!
<marler8997>
ikskuh, well what's you'r stance on C++ here then?
<marler8997>
Zero Cost Abstraction™
<marler8997>
definitely not all of it
<marler8997>
some of it was productive
<marler8997>
ikskuh, do you agree so we can move on from this topic?
<marler8997>
THANK YOU!!
<marler8997>
I can't make the TradeMark symbol like fengb :(
<marler8997>
TM
<marler8997>
but he was saying C++ "Zero Cost Abstraction" is excludes optimization
<marler8997>
yeah that's true I suppose
<marler8997>
andrewrk, do you agree with ikskuh on that claim?
<ikskuh>
marler8997: yes
<marler8997>
ikskuh, are you still holding to your claim that zero cost abstraction is orthogonal to optimization?
<marler8997>
I'm always talking about runtime cost when saying "zero cost abstraction", because well, the abstraction itself will by definition have a different comptime cost
<marler8997>
right, I was talking about runtime cost
<earnestly>
marler8997: (The code that your compiler generates from either sum(a,b) or a+b does not need to be optimal, reliable, constant-time, etc. They only have to be the same)
<marler8997>
andrewrk is saying they may not in some cases in the future
<marler8997>
currently yes
<ikskuh>
marler8997: zig vtables have actual cost
<marler8997>
andrewrk, right, but that contradicts ikskuh's claim that zero cost abstraction has nothing to do with optimization
<andrewrk>
marler8997, fwiw I was purposefully avoiding trying to define "zero cost abstractions" in our discussion and the only claim I made was that specifically for the Allocator interface, I thought there could exist an additional LLVM pass that would make it be able to devirtualize the function pointers
<marler8997>
For anyone wanting to know what C++ means by Zero Cost Abstraction, watch "There are no Zero-cost Abstractions" here: https://www.youtube.com/watch?v=rHIkrotSwcc
<marler8997>
earnestly I don't see what you're saying... :(
<marler8997>
you're too much TheLemonMan
<marler8997>
omg
<TheLemonMan>
I, for one, would like more marler8997 in the compiler
<earnestly>
marler8997: You literally provided one in your definition, a+b and sum(a,b) in terms of the code it generates
<marler8997>
earnestly, representation?
<earnestly>
marler8997: Sounds like confusing representation and optimisation again :P
<marler8997>
He claims the allocator interface can be zero cost with the help of the optimizer
<marler8997>
Andrew himself has said that's also not what he means by zero cost
<marler8997>
companion_cube, I agree that's a good goal, but I'm just saying that's not what C++ people mean. C++ people are ok to call an abstraction 0 cost if it only is so with the help of the optimizer
<companion_cube>
marler8997: just add "for all compilers" and we agree
<marler8997>
Note that this depends on the optimizer, the compiler, alot of things
<marler8997>
Here are my definitions. You have code A and code B. They do the same thing but A is an "abstraction" of B. For example, B could be "a+b" and A could be "sum(a,b)". With these defintions, A is said to be a "Zero Cost Abstrcation" if it generates the same binary code as B.
<marler8997>
I have a bachelor's in general mathematics
<marler8997>
yes
<earnestly>
marler8997: Do you know what a venn diagram is?
<marler8997>
how what can cross over? huh?
<earnestly>
marler8997: Sorry, I thought you'd understand how they can cross over
<marler8997>
you said that like 15 lines up
<marler8997>
earnestly, you said " It doesn't exclude them, but they're not related"
<earnestly>
marler8997: I never said unrelated. A venn diagram would include both. The point isn't about optimisation, although it's often one of the goals
<marler8997>
again, please be careful with 'zero cost'....in this case zero cost means that the generated code is the same as it would have been without the abstraction
<marler8997>
earnestly claims they are unrelated
<marler8997>
what's under question is if Zero Cost Abstraction is related to optimization
<marler8997>
companion_cube, reliability is irrelevant here
<justin_smith>
marler8997: in order to say *the abstraction* is zero cost, it needs to be generally zero cost, not merely in special cases as an optimizer would find
<marler8997>
that one confuzzles me
<marler8997>
so optimizations *can* be used to implement zero cost abstrations, but zero cost abtractions aren't related to optimizations?
<marler8997>
maybe I'm missing something?
<marler8997>
ok...can you explain that one more?
<marler8997>
I don't see how what you said excludes optimizations from being used to implement zero cost abstractions
<earnestly>
marler8997: You keep confusing abstractions with runtime performance and optimisation
<marler8997>
earnestly, I agree with what you're saying, but am not sure what point you were trying to make?
<marler8997>
earnestly, yeah that sounds right
<marler8997>
earnestly I'm confused
<earnestly>
marler8997: Give yourself a few minutes
<marler8997>
does that include compiler CPU cycles, or just the generated program?
<earnestly>
marler8997: CPU cycles
<marler8997>
earnestly, depends what you mean by zero cost
<marler8997>
of vtables...I suppose you could say it that way
<ikskuh>
marler8997: classes in C++ are a zero-cost abstraction over coding the object orientation by hand
<earnestly>
marler8997: He said, vtables
<marler8997>
he says C struct, but I don't know what he means by that
<marler8997>
zero cost abstractions of what?
<marler8997>
at the moment I'm trying to get companion_cube to clarify what he means by saying that classes are zero cost abstractions
<justin_smith>
marler8997: you are you attempting to describe an abstraction, or a specific usage of that abstraction, when you apply the adjective "zero cost"
<marler8997>
zero cost != Zero Cost Abstraction
<marler8997>
novaskell, I agree, but that's not what is meant by "Zero Cost Abstraction"
<marler8997>
so yes, you're right
<marler8997>
justin_smith, it's only a zero cost abstraction if the optimizer can inline it
<marler8997>
can you provide me with the example?
<justin_smith>
marler8997: one function call's cost can be optimized away, but "the abstraction" here is "function call", which cannot in the general case be zero cost, even in c++ definition, you can't call an abstraction itself 0 cost if only certain highly constrained usages can be optimized
<marler8997>
according to the C++ definition
<marler8997>
irrelevant to whether it's a zero cost abstraction
<marler8997>
yes
<marler8997>
but it's not the same as the C++ definition
<marler8997>
it doesn't conform to ikskuh's definition of Zero Cost
<marler8997>
again, that's what C++ means by Zero Cost Abstraction
<marler8997>
ok, so just provide me with the specific code and the abstracted code of what you're trying to say
<marler8997>
so using foo(a, b) is an abstraction of a+b....but if the optimizer inlines it, then now it is a zero cost abstraction
<marler8997>
foo(a, b)
<marler8997>
could be abstracted with int foo(int a, int b) { return a + b; }
<marler8997>
the code a+b
<marler8997>
I can give you an inline function example
<companion_cube>
marler8997: the whole vtable is abstracted!!!!
<marler8997>
for example
<marler8997>
what specific code are you saying is being abstracted
<marler8997>
you need to be more specific
<marler8997>
C++ classes aren't an abstraction of C structs
<marler8997>
C structs and C++ Classes are two different things
<marler8997>
so what specifically are you saying?
<marler8997>
you are saying that coding X will yield no runtime cost than coding Y
<marler8997>
when you say something is a "0 cost abstrcation"
<marler8997>
abstraction is a relative term
<marler8997>
again
<marler8997>
abstraction doesn't mean, thing X does more things than thing Y, so X is an abstraction of Y
<marler8997>
that's not what abstraction means
<marler8997>
classes are not an abstraction so POD structs
<marler8997>
companion_cube
<marler8997>
when you use it, you need a specific implementation in mind from which the abstraction is derived
<marler8997>
ok, abstraction is a relative term
<marler8997>
because structs and classes are the same in C++
<marler8997>
structs can also have virtual methods in C++
<marler8997>
that's not what "classes" are, that's a virtual method
<companion_cube>
(@ marler8997)
<marler8997>
structs have a default visibility of public and classes default visibility is private
<marler8997>
the only difference, is the default visibiily
<marler8997>
they are literally the same thing in C++
<marler8997>
classes are not an abstraction of structs, classes are structs
<marler8997>
functions are an abstractions of hand-written inline code
<marler8997>
goodness
<marler8997>
classes are not an abstraction of structs
<marler8997>
they are the same thing
<marler8997>
classes are structs
<marler8997>
companion_cube, I don't know what you mean by all classes are 0 cost abstractions
<marler8997>
but C++ claims alot of abstractions are zero cost that could only be so with optimization
<marler8997>
yes I agree
<marler8997>
if that's the defintion you use, then C++ is definitely NOT zero cost
<marler8997>
ikskuh, again, you're just definining what "zero-cost" means to you, but be careful because that's not what it means to everyone
<marler8997>
and that's actually one of the biggest weaknesses I see with removing generics
<marler8997>
which I think is GREAT!!!!
<marler8997>
you're saying that you're definition of 0-cost means it must be guaranteed
<marler8997>
it depends on what you mean by zero-cost...all you're doing is trying to define what you mean by "zero-cost"
<marler8997>
but that's not what Zero Cost Abstraction means
<marler8997>
"zero-cost"
<marler8997>
ikskuh yes I can agree with that
<marler8997>
However, ikskuh claimed that Zero Cost Abstrcations and the optimizer are orthogonal, in C++
<marler8997>
whether or not zero cost abstractions should rely on the optimizer is actually a very interesting topic
<marler8997>
I never said it shouldn't rely on the optimizer
<marler8997>
dominkh, THAT IS FINE
<marler8997>
ALL I AM SAYING, is that Zero Cost Abstractions does not exclude the optimizer
<marler8997>
I'm not saying it should or should not rely on the optimizer
<marler8997>
I am not saying that Zero Cost Abstractions require the optimizer
<marler8997>
you guys are arguing against a claim I am not making
<companion_cube>
marler8997: it means the optimizer can't fuck it up
<marler8997>
I can't
<marler8997>
I don't even know what to say to that
<marler8997>
because it is still true for "no optimizer"?????
<marler8997>
how can that not include the optimizer!
<marler8997>
yes!
<marler8997>
I'm countering the claim that C++'s Zero Cost Abstractions exclude the optimizer entirely, that they are orthogonal
<marler8997>
I'm not making a claim that all zero cost abstractions require the optimizer
<marler8997>
oh my goodness
<marler8997>
I specially asked about the "optimizer"
<marler8997>
ikskuh, you didn't answer the question
<marler8997>
If you still hold that, I'm pretty sure I can find some videos from Stroustrup where he talks about Zero Cost Abstraction in terms of function inlining and vtables
<marler8997>
is that right?
<marler8997>
you're saying that an optimizer optimizing away function calls, classes, indirction, vtables, none of that is included in Zero Cost Abstraction
<marler8997>
When a C++ programmer says "Zero Cost Abstraction"
<marler8997>
no, in C++'s definition
<marler8997>
but ikskuh is claiming Zero Cost Abstraction is orthogonal to optimization
<marler8997>
companion_cube of course
<marler8997>
but ikskuh says that's not what C++ is saying?
<marler8997>
yeah that would be a cool feature
<marler8997>
Maybe we need to look this up and see what C++ is claiming
<marler8997>
ikskuh oh?
<marler8997>
I said, it's definition of Zero Cost Abstraction doesn't exclude the optimizer
<marler8997>
I didn't say it requires
<marler8997>
but again, that's not the definition C++ uses
<marler8997>
ikskuh, well that followd by your definition of zero cost
<marler8997>
but if that's your definition, then your claim follows
<marler8997>
I don't know where you got your definition from though
<marler8997>
your definitly specifically excluded the optimizer for some reason...
<marler8997>
but your definition did
<marler8997>
the definition doesn't specify what component removes the runtime cost
<marler8997>
the runtime cost could be taken care of by the optimizer, or templates, whatever
<marler8997>
The definition C++ uses, is it is an Abstraction that has no runtime cost
<marler8997>
you're using a custom definition I'm not familiar with
<marler8997>
that's not what C++ means by Zero Cost Abtraction
<marler8997>
however
<marler8997>
so now I see where we were differing
<marler8997>
you definitions infers your claim :)
<marler8997>
lol
<marler8997>
what do you mean by "Zero Cost Abstraction"?
<marler8997>
so maybe our definitions are just different
<marler8997>
your claim was, Zero Cost Abstraction has nothing to do with optimization
<marler8997>
ikskuh, I'm not sure what that has to do with discussing your claim
<marler8997>
what?
<marler8997>
I assume an optimizer?
<marler8997>
it means "no runtime penalty"
<marler8997>
zero cost doesn't mean 0 cost on everything
<ikskuh>
marler8997: you asume an optimizer
<marler8997>
again
<marler8997>
that's the whole point
<marler8997>
novaskell, with the optimizer a function call can generate runtime code equivalent to a macro
<novaskell>
a function is not zero cost though marler8997 unless you implement all "functions" as plain macro expansions
<marler8997>
what is your definitino of "zero cost abstraction"?
<marler8997>
ikskuh what do you mean by that?
<marler8997>
funtion inlining is a counter example to that claim
<marler8997>
the function
<marler8997>
and I gave a very simple couter example
<marler8997>
that they are orthogonal
<marler8997>
ikskuh made a very bold claim that zero cost abstrcations have NOTHING to do with optimization
<marler8997>
but that's not what we're discussing
<companion_cube>
marler8997: domi<tab> will help
<marler8997>
companion_cube yes of course
<marler8997>
zero cost means you abstracted details away, but didn't pay a runtime penalty
<marler8997>
if it got optimized away, then it became a zero cost abstraction
<marler8997>
dominkh, you just proved my point again
<marler8997>
but he is claiming that all zero cost abstractions are orthogonal to the optimizer
<marler8997>
yes templates are an example of a zero cost abstraction that doesn't use the optimizer
<marler8997>
not "orthogonal sometimes"
<marler8997>
but ikskuh claims they are orthogonal
<marler8997>
companion_cube sure
<marler8997>
"we would disagree with C++"? what?
<marler8997>
but you're saying it doesn't?
<marler8997>
c++ relies on the optimizer to claim it supports zero cost abtraction
<marler8997>
thus, you proved my point
<marler8997>
and you said, it's only zero cost if the optimizer inlines it
<marler8997>
my point is that zero cost abstractions and the optimizer are not orthogonal
<marler8997>
dominkh, you just proved my point
<marler8997>
zero cost is referring to runtime
<marler8997>
and I'm giving you counter examples to that
<marler8997>
but you said that zero cost abstractions and the optimizer are orthogonal
<marler8997>
yes
<marler8997>
it is a "zero cost abstraction" which means that if it doesn't semantically need to be a function at runtime, the compiler can choose to inline it
<marler8997>
it's an abstraction in that it abstractions the context of the caller away from what the function is doing
<marler8997>
a function is an abstraction of embedding code directly
<marler8997>
it only has zero cost when the optimizer can optimzie it away
<marler8997>
you can abstract logic by putting it into a function, but that has a runtime cost
<marler8997>
very simple example is a function call
<marler8997>
you don't need to get that complicated
<marler8997>
huh?
<marler8997>
but it requires the optimizer for them to be zero cost
<marler8997>
so you're saying c++ doesn't have zero cost abstractions?
<marler8997>
what?
<marler8997>
ikskuh
<marler8997>
C++ prides itself on zero cost abstractions
<marler8997>
so...what does C++ mean by zero cost abstractions?
<marler8997>
zero cost abstractions is orthogonal to the optimizer...?
<marler8997>
ikskuh...uh what?
<marler8997>
Removing generics means we won't have Zero Cost abstraction unless..there is a path for the optimizer
<marler8997>
I bring the optimizer up because I think ZeroCost abstraction is very important and necessary
<marler8997>
gotcha
<marler8997>
in some cases yes, in some cases no
<marler8997>
I assumed the compiler might optimize away all AnyType?
<ikskuh>
marler8997: you assumed that the compiler might optimize away all AnyType
<marler8997>
the question I thought we were on was is there a way to allow AnyType to decompose to values without using generics?
<marler8997>
was that fact up for debate somehow?
<marler8997>
ikskuh, yeah I agree
<ikskuh>
marler8997: was just talking about that the optimizer cannot optimize certain things
<marler8997>
sorry I'm a bit lost on our thread, what was the point you were making?
<marler8997>
iksuh, yes I agree, I don't need to see an example to agree with that
<ikskuh>
marler8997: optimizer cannot optimize indirection with side effects
<marler8997>
iksuh what is your example trying to show?
<marler8997>
but some of the things people bring up don't necessarily apply
<marler8997>
justin_smith both are good
<justin_smith>
marler8997: so you want an explanation in abstract terms, instead of specific examples of things that would not work?
<marler8997>
that's what the discussion is for
<marler8997>
but I want to understand specifically how it breaks the language
<marler8997>
justim_smith, I think you're right
<justin_smith>
marler8997: it's not the idea that breaks the language, it's the feature as you describe it, and other people are explaining why it would break the language, I don't see the problem
<marler8997>
to gain mutual understanding
<ikskuh>
i think marler8997 didn't see the "dangling pointer" problem
<marler8997>
to understand what makes features good or bad
<marler8997>
dominkh to learn
<marler8997>
I'm trying to have a discussion
<marler8997>
I'm not proposing features
<marler8997>
justin_smith, again that's not the point whether these ideas break the language
<justin_smith>
marler8997: right, they effect the language by breaking it (or creating some very weird special cases, arguably equivalent)
<marler8997>
dominkh, yes, I'm not saying these ideas don't break the language,
<marler8997>
the purpose isn't to know whether they are good ideas, it's how would these features affect the language...
<marler8997>
I'm talking about how these features would affect the language and then people are coming back with, "yeah but I don't like that idea because X"
<justin_smith>
marler8997: I think they are plainly describing how the change you describe would break the language semantics