2020-12-03

<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
<companion_cube> https://godbolt.org/z/anvT3T @ marler8997
<marler8997> cause if so, then operator overloading is only zero cost if the optimizer inlines it correct?
<marler8997> your defintion?
<marler8997> ikskuh, which zero cost are you using?
<marler8997> sure I'll agree with that
<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
<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> can you provide me with the example?
<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> No one ever said they were
<marler8997> companion_cube of course
<marler8997> a function is an abstraction
<marler8997> the act of the optimizer inlining a function can make abstracting code into a function a Zero Cost Abstraction
<marler8997> not the inline keyword
<marler8997> function inlining is another
<marler8997> I think c++ iterators are one feature that requires optimization
<marler8997> I recall this video: https://www.youtube.com/watch?v=zBkNBP00wJE
<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
<companion_cube> marler8997: domi<tab> will help
<marler8997> but that's not what we're discussing
<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