On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:
> Keywords are considered to be incredibly expensive. Being able to use a name
> starting with @ rather than a keyword does reduce the cost, but you're still
> going to have to drive a very hard bargain to talk Walter into adding anything
> like that to the language at this point. Adding much of _anything_ to the
> language is generally considered expensive.

I'm not sure if you meant the same, but I meant the word "cost" of a feature as "the amount the feature complicates the language". Also, I'm only asking people to "buy" this feature in the sense of: "what would you say about this feature if the language was still back on the drawing board and nothing had been written down yet".

On Tuesday, October 02, 2012 01:19:51 Tommi wrote:
> I'm not sure if you meant the same, but I meant the word "cost" of a feature as "the amount the feature complicates the language". Also, I'm only asking people to "buy" this feature in the sense of: "what would you say about this feature if the language was still back on the drawing board and nothing had been written down yet".

No offense, but a feature proposal is pretty pointless if it's a "this would have been nice had we had thought of it when we could have easily added it." A feature proposal is only relevant if it's really an attempt to change the language now.

If we were really back at the drawing board, there are plenty of other things which would change, some of which could completely change how some things work and possibly invalidate a feature which might seem reasonable now but wouldn't work with the other changes (which probably isn't the case here, but still, discussing what could have been doesn't really buy us anything IMHO).

- Jonathan M Davis

On Mon, Oct 1, 2012 at 4:19 PM, Tommi <tommitissari@hotmail.com> wrote:

> On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:
>
>> Keywords are considered to be incredibly expensive. Being able to use a
>> name
>> starting with @ rather than a keyword does reduce the cost, but you're
>> still
>> going to have to drive a very hard bargain to talk Walter into adding
>> anything
>> like that to the language at this point. Adding much of _anything_ to the
>> language is generally considered expensive.
>>
>
> I'm not sure if you meant the same, but I meant the word "cost" of a feature as "the amount the feature complicates the language". Also, I'm only asking people to "buy" this feature in the sense of: "what would you say about this feature if the language was still back on the drawing board and nothing had been written down yet".
>

That is a close to useless exercise (or domain problem). Problems to solve are only interested in a specific domain. In other words the problem as you have defined it will have a different solution in D, C++, Java, vaporware language, etc.

To some degree it reminds me of the slew of TCP replacement protocols that academia has designed and implemented that will probably never see the day of light. Don't get me wrong it is educational to read them and implementable in private networks but it is highly probably that the Internet will never see them.

Thanks,
-Jose

Jonathan M Davis:

> Adding much of _anything_ to the
> language is generally considered expensive.

Sometimes you add from a language removing something, like allowing handy code like this, removing such limitations and making the language more regular/uniform:


class Foo {
    int x, y;
}
struct Bar {
    int x, y;
}
void main() {
    auto f1 = new Foo(1, 2);
    auto f2 = new Foo(1);
    auto b1 = new Bar(10, 20);
    auto b2 = new Bar(10);
}

Bye,
bearophile

On 10/1/12 5:55 PM, Tommi wrote:
> On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
>> The question is whether it's worth adding such an attribute to
>> the language, and clearly, most of us think that explicitly
>> using enum suffices whereas Tommi wants such a function
>> attribute.
>
> You'd get simpler syntax at the cost of just one lousy new keyword. It's
> a once in a life time deal! Any takers?

I understand the motivation. We will not consider such a feature for the time being.

Andrei

On Monday, 1 October 2012 at 23:31:21 UTC, Jonathan M Davis wrote:
> No offense, but a feature proposal is pretty pointless if it's a "this would
> have been nice had we had thought of it when we could have easily added it." A
> feature proposal is only relevant if it's really an attempt to change the
> language now.
>
> If we were really back at the drawing board, there are plenty of other things
> which would change, some of which could completely change how some things work
> and possibly invalidate a feature which might seem reasonable now but wouldn't
> work with the other changes (which probably isn't the case here, but still,
> discussing what could have been doesn't really buy us anything IMHO).
>
> - Jonathan M Davis

I don't think you should stop trying to write the best language specification you can just because you're past the point of it being implementable by this language. Call the specification D++ and maybe some day someone will pick it up and try to implement it.

On Tuesday, October 02, 2012 02:19:21 Tommi wrote:
> I don't think you should stop trying to write the best language specification you can just because you're past the point of it being implementable by this language.

Discussing changes to D2 is of relevance, because that affects what we're doing now. Discussing features for a possible D3 is of some relevance, because it could eventually affect the language (but is also kind of pointless in that it won't matter for years yet). Discussing features simply because they might have been nice but we don't intend to ever add them is utterly pointless IMHO.

Aside from D, discussing your dream language is all well and good, but it's not really going to help D if the discussion isn't aimed at improving D as it is now.

> Call the specification D++
> and maybe some day someone will pick it up and try to implement
> it.

Um. That would actually be bad from our point of view. We don't want to fragment the community. D will evolve, and we may even eventually end up with D3, and someone may very well create a D++ someday, but it's not really in our best interest to promote the creation of such a language (especially not now). We want D to succeed, and it's going to have to do that pretty much as it is now.

At some point, you have to make what you have work and get it to gain traction in the programming community as it is, or what you have is of little practical value. Forever tweaking it won't get you there even if the tweaks create what is theoretically a better language.

So, feel free to air your ideas, but if they're not of practical value towards improving D right now, many of us aren't going to pay much attention to them.

- Jonathan M Davis

On 10/1/2012 1:10 PM, Tommi wrote:
> I meant that all functions would still be
> implicitly CTFEable by default, but an attribute like force_ctfe would
> make it so that the function is guaranteed to execute at compile-time
> when its arguments are compile-time constants.

Since all you need to do to guarantee compile time evaluation is use it in a context that requires CTFE, which are exactly the cases where you'd care that it was CTFE'd, I just don't see much utility here.

Note that it is also impossible in the general case for the compiler to guarantee that a specific function is CTFE'able for all arguments that are also CTFE'able.

On Monday, 1 October 2012 at 22:47:48 UTC, Timon Gehr wrote:

>
> A D compiler is also a D interpreter. I wouldn't even bother with D if this wasn't the case.

A D compiler _contains_ a limited interpreter for constant expression evaluation. This has limitations such as not being able to perform IO at compile-time (there's a special pragma for that). This is merely an outgrowth of a compiler optimization technique.

Now, back on topic:
I agree with Jonathan - in general the compiler can't evaluate _all_ functions at-compile time due these limitations of CTFE and adding a compiler flag will make compilation times far worse than c++. Adding a function attribute adds marginal benefit over simply assigning to a static/enum variable.

On 01/10/12 07:40, Tommi wrote:
> import std.stdio;
>
> int pow2(int val) pure
> {
>      if (__ctfe)
>          return 6;
>      else
>          return val * val;
> }
>
> void main()
> {
>             assert(pow2(3) == 9);
>      static assert(pow2(3) == 6);
>
>      writeln("9 = 6 ... I knew it! '6' was faking it all along");
>      readln();
> }

You don't need the if (__ctfe) to show this behaviour. Nor do you even need CTFE at all (though it would be a bit less obvious). You could demonstrate it in C++ too.

Any code that behaves differently when compiled with -O, will do this as well. Constant folding of floating point numbers does the same thing, if the numbers are represented in the compiler in a different precision to how the machine calculates them. I believe that GCC, for example, uses very much higher precision (hundreds of bits) at compile time.