kenji hara:

> Is this really need?

> ...But, I would never opposed to advancing toward the better language design.

I am not expert on English language, but you are one of my programming heroes, so please let me try to improve a little those parts of your post :-)

| Is this really necessary?

| ...but, I would never be opposed to an advancement toward that better
| language design.

Or simply:

| ...but, I am not opposed to advance to that better language design.

Bye,
bearophile

On 12/07/2012 13:41, bearophile wrote:
> Another weapon to attack the problem is introducing in the DMD back-end
> an optimization (already present in LLVM, but I think not used on
> default), merging of functions with the same body (leaving just a jump
> as the body of the removed function, to keep their function pointers
> distinct).
>

That is IMO the way to go instead of cluttering the language.

On 12/07/2012 16:28, kenji hara wrote:
> Is this really need?
>
> The four const operators in Object should not block the user-defined
> mutable operators.
>
> // My purpose for 2.060 release
> class C {
>    override opEquals(const Object o) const { ... } // or just alias
> super.opEquals opEquals;
>    bool opEquals(Object o) { ... } // add overload for mutable object comparison
> }
>
> auto c1 = new C(), c2 = new C2();
> c1 == c2;   // the both hand side is mutable, so mutable opEquals will run
>
> In git head, it is not disallowed, but it is a *compiler bug*.
> To fix the problem, I have a pull request for dmd.
> https://github.com/D-Programming-Language/dmd/pull/1042
> (The pull will kill attribute inference for const, but I think it is
> unnecessary for D.)
>
> ...But, I would never opposed to advancing toward the better language design.
>

mutable and const overload of the same function is a bit weird. I'm not sure this is a bug a feature we should keep.

On 7/12/12 10:28 AM, kenji hara wrote:
> Is this really need?
>
> The four const operators in Object should not block the user-defined
> mutable operators.
>
> // My purpose for 2.060 release
> class C {
>    override opEquals(const Object o) const { ... } // or just alias
> super.opEquals opEquals;
>    bool opEquals(Object o) { ... } // add overload for mutable object comparison
> }
>
> auto c1 = new C(), c2 = new C2();
> c1 == c2;   // the both hand side is mutable, so mutable opEquals will run
>
> In git head, it is not disallowed, but it is a *compiler bug*.
> To fix the problem, I have a pull request for dmd.
> https://github.com/D-Programming-Language/dmd/pull/1042
> (The pull will kill attribute inference for const, but I think it is
> unnecessary for D.)

I didn't know of that, thanks.

> ....But, I would never opposed to advancing toward the better language design.

Thanks for being so helpful and flexible! Let's discuss matters a little more in this forum before making a decision.


Andrei

On 12/07/2012 13:50, Tobias Pankrath wrote:
>> Another weapon to attack the problem is introducing in the DMD
>> back-end an optimization (already present in LLVM, but I think not
>> used on default), merging of functions with the same body (leaving
>> just a jump as the body of the removed function, to keep their
>> function pointers distinct).
>
> Why not drop that requirement? What is the use case of different
> function pointers for different but equivalent functions? Does anyone
> depend on this?

Nothing prevent the linker to link directly to the new function if the body is only a branch instruction. This have a cost only when doing indirect call, and the indirect call is greater than a branch instruction.

On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
[...]
> >3. opCmp, opEquals, and toHash are all needed primarily for one thing: built-in hashes. (There's also use of them in the moribund .sort method.) The thing is, the design of built-in hashes predates the existence of templates. There are reasons to move to generic-based hashes instead of today's runtime hashes (such as the phenomenal success of templated containers in C++), so it can be argued that opCmp, opEquals, and toHash exist for reasons that are going extinct.
> 
> Yes.  Where's that new AA struct, Mr. Teoh? :)
[...]

The code is still here:

	https://github.com/quickfur/New-AA-implementation

But I got roadblocked, partially because of constness issues (ironically, the problem was that toHash, toString, etc., weren't const, and now we're talking about supporting non-const versions of them), but more because of problems with IFTI. Or at least, that's where I left it about a month ago -- then I was away on vacation and haven't had the chance to go back to the code since. :(


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

deadalnix:

> That is IMO the way to go instead of cluttering the language.

I think several solutions applied at the same time are needed if you desire to reduce bloat effectively.

Bye,
bearophile

On 12/07/2012 15:20, Michel Fortin wrote:
> On 2012-07-12 11:41:46 +0000, "bearophile" <bearophileHUGS@lycos.com> said:
>
>> Andrei Alexandrescu:
>>
>>> The issue is template code bloat. My impression from being in touch
>>> with the C++ community for a long time is that virtually nobody even
>>> talks about code bloat anymore. For whatever combination of industry
>>> and market forces, it's just not an issue anymore.
>>
>> There is no proof that template bloat won't be a problem in D (I
>> remember the first version of the D Objective-C bridge failing because
>> of code bloat, the second version seems to require changes in the D
>> language).
>
> I don't think templates were the culprit for the D/Objective-C bridge.
> Code bloat was, but that's something that was inherent to the design of
> the bridge. The bridge was using mixins extensively, and while I did
> everything I could to use regular non-mixin templates (because those can
> be reused when the template arguments are the same), it wasn't enough.
> In fact, given that all the wrapper functions written using mixins were
> virtual (so you could override them, which is quite a feature!) it meant
> they all needed to be instantiated even though they were not used anywhere.
>
> There's actually no way I could have reduced code bloat significantly
> even by writing all the code by hand in the most optimized way. Not
> unless I abandoned the capability to override functions, but that'd make
> the bridge almost useless.
>
> One thing that might have helped is if the linker could have striped all
> the classes that were not used in the final executable, something it
> couldn't do because all module info refers to them. But that wouldn't
> have helped with the compilation speed, which was becoming the second
> problem not far behind code bloat.
>
>
>> And it seems L1 code caches of CPUs aren't growing a lot (so I suggest
>> to not ignore having lot of code to swap in and out of those 32 kbytes).
>>
>> So maybe it will be useful to introduce in D some means to attack the
>> code bloat problem from several sides at the same time.
>>
>> Some time ago I have suggested one of such weapons, the @templated()
>> that allows to select what parts of a struct/class are templated
>> regarding to what template arguments (it's a refinement of an idea of
>> Stroustrup).
>>
>> Another weapon to attack the problem is introducing in the DMD
>> back-end an optimization (already present in LLVM, but I think not
>> used on default), merging of functions with the same body (leaving
>> just a jump as the body of the removed function, to keep their
>> function pointers distinct).
>
> Both desirable things, but I don't think those would have much impact on
> the D/Objective-C bridge.
>
>

I think this is not a problem as big as it is stated.

Most of that code will be executed close to never, and 60Mb isn't a big deal for any modern computer, not even for most cell phones now.

On 12/07/2012 16:55, bearophile wrote:
> deadalnix:
>
>> That is IMO the way to go instead of cluttering the language.
>
> I think several solutions applied at the same time are needed if you
> desire to reduce bloat effectively.
>
> Bye,
> bearophile

The @templated is redundant with that backend capability of LDC.

deadalnix:

> The @templated is redundant with that backend capability of LDC.

The semantics is not the same. This code doesn't compile, the compiler enforces you are not using T in code that is annotated to be a template of just V:


struct Foo(T, V) {
  @templated(V) T bar() { return T.init; }
}


Bye,
bearophile