On Friday, 8 July 2016 at 19:43:39 UTC, jmh530 wrote:
> On Friday, 8 July 2016 at 18:16:03 UTC, Andrei Alexandrescu wrote:
>>
>> You may well be literally the only person on Earth who dislikes the use of "static" in "static if". -- Andrei
>
> You have to admit that static is used in a lot of different places in D. It doesn't always mean something like compile-time either. For instance, a static member function is not a compile time member function. However, I doubt something like this is going to change, so it doesn't really bother me.
>
> I liked the way that the Sparrow language (from the presentation you posted a few weeks ago) did it. Instead of static if, they use if[ct].

I like static if :)

On Fri, Jul 08, 2016 at 08:01:10PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Friday, 8 July 2016 at 19:43:39 UTC, jmh530 wrote:
> > On Friday, 8 July 2016 at 18:16:03 UTC, Andrei Alexandrescu wrote:
> > > 
> > > You may well be literally the only person on Earth who dislikes the use of "static" in "static if". -- Andrei
> > 
> > You have to admit that static is used in a lot of different places in D.  It doesn't always mean something like compile-time either. For instance, a static member function is not a compile time member function. However, I doubt something like this is going to change, so it doesn't really bother me.
> > 
> > I liked the way that the Sparrow language (from the presentation you posted a few weeks ago) did it. Instead of static if, they use if[ct].
> 
> I like static if :)

I like static if too. I think if[ct] is more awkward to type, even though it's fewer characters.

But yeah, D *has* overloaded the "static" keyword perhaps a little more than it ought to have.  But at the end of the day it's just syntax... there are far more pressing issues to worry about than syntax at the moment.


T

-- 
If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell

On 7/7/2016 7:25 PM, Andrew Godfrey wrote:
> "static" is a terribly non-descriptive name

That's why it's the go-to keyword for any functionality we can't think of a good name for, or if the name would be too long such as "launch_nucular_missiles".

On 07/08/2016 08:42 PM, deadalnix wrote:
> It is meaningless because sometime, you have A and B that are both safe
> on their own, but doing both is unsafe. In which case A or B need to be
> banned, but nothing allows to know which one.

Would you mind giving an example? Purely to educate me.

> This isn't a bug, this is
> a failure to have a principled approach to safety.

The principled approach would have been to start with an empty set of features in @safe and then add stuff after verifying that it's safe on its own and in combination with what's already there. Right?

If that's it, then that does seem better to me, yeah. But I'd say that the unprincipled approach has led to bugs (or maybe call it holes in the spec).

And what I tried to say is that the dictatorship at least acknowledges those bugs/holes and agrees that they need fixing. Whereas they're apparently just fine with the silly limitation of alias parameters that you pointed out.

> The position is inconsistent because the dictatorship refuses to
> compromise on mutually exclusive goals. For instance, @safe is defined
> as ensuring memory safety. But not against undefined behaviors (in fact
> Walter promote the use of UB in various situations, for instance when it
> comes to shared). You CANNOT have undefined behavior that are defined as
> being memory safe.

What you say makes sense to me. Seems silly when the compiler guards me against memory-safety errors but not against undefined behavior.

On 08.07.2016 04:25, Andrew Godfrey wrote:
>
> Another example is "return" used for monads in eg Haskell - even if it
> only has one meaning in Haskell, it is too mixed up with a different
> meaning in other common languages. D's "static if" - which is a killer
> feature if I ignore the keyword - gives me a similar feeling (though
> it's much less egregious than "return" in monads).

'return' in Haskell is perfectly fine.

On 7/7/2016 5:56 PM, deadalnix wrote:
> While this very true, it is clear that most D's complexity doesn't come from
> there. D's complexity come for the most part from things being completely
> unprincipled and lack of vision.

All useful computer languages are unprincipled and complex due to a number of factors:

1. the underlying computer is unprincipled and complex (well known issues with integer and floating point arithmetic)

2. what programmers perceive as logical and intuitive is often neither logical nor intuitive to a computer (even Haskell has wackadoodle features to cater to illogical programmers)

3. what the language needs to do changes over time - the programming world is hardly static

4. new features tend to be added as adaptations of existing features (much like how evolution works)

5. new features have to be worked in without excessively breaking legacy compatibility

6. no language is conceived of as a whole and then implemented

7. the language designers are idiots and make mistakes


Of course, we try to minimize (7), but 1..6 are inevitable.

On 08.07.2016 21:26, Andrei Alexandrescu wrote:
> Where is the reference to Walter's promotion of UB in @safe code?

Only found this, but IIRC, there was another discussion:

http://www.digitalmars.com/d/archives/digitalmars/D/C_compiler_vs_D_compiler_272670.html#N272689

On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
> On 7/7/2016 5:56 PM, deadalnix wrote:
>> While this very true, it is clear that most D's complexity doesn't come from
>> there. D's complexity come for the most part from things being completely
>> unprincipled and lack of vision.
>
> All useful computer languages are unprincipled and complex due to a number of factors:

I think this is a very dangerous assumption. And also not true.

What is true is that it is difficult to gain traction if a language does not look like a copy of a pre-existing and fairly popular language.

On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:
> On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
>> On 7/7/2016 5:56 PM, deadalnix wrote:
>>> While this very true, it is clear that most D's complexity doesn't come from
>>> there. D's complexity come for the most part from things being completely
>>> unprincipled and lack of vision.
>>
>> All useful computer languages are unprincipled and complex due to a number of
>> factors:
>
> I think this is a very dangerous assumption. And also not true.

Feel free to post a counterexample. All you need is one!


> What is true is that it is difficult to gain traction if a language does not
> look like a copy of a pre-existing and fairly popular language.

I.e. Reason #2:

"what programmers perceive as logical and intuitive is often neither logical nor intuitive to a computer"

On 7/8/2016 2:33 PM, Timon Gehr wrote:
> On 08.07.2016 21:26, Andrei Alexandrescu wrote:
>> Where is the reference to Walter's promotion of UB in @safe code?
>
> Only found this, but IIRC, there was another discussion:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/C_compiler_vs_D_compiler_272670.html#N272689


I don't agree with the notion that all UB's can lead to memory corruption. deadalix's hypothetical fails because "proving it always passes" cannot be done at the same time as "remove this code path because it is undefined".

I don't agree with the interpretation of UB in C++ that some C++ compiler authors do for that reason.