On Sunday, 12 March 2017 at 08:03:46 UTC, Jerry wrote:
> On Tuesday, 7 March 2017 at 21:34:35 UTC, Walter Bright wrote:
>> On 3/7/2017 9:45 AM, Atila Neves wrote:
>>> 1 warning generated.
>>
>> Pretty much all C++ compilers will generate warnings for this. The thing about warnings, though, is they imply that there are situations where the code is acceptable. I can't think of any. It needs to be an error. It should never pass the compiler.
>
> What about Ketmar's example? It seems to have been glossed over.

We've discussed it quite thoroughly...
Again IMO it's not a good idea to require opEquals and others to be @pure. Not much of a discussion really since it would be a breaking change, besides the opposite of an improvement.

Again the only good possibility I can think if we really really want to disallow a==b etc. for custom types, is to add a new feature to the specification. This change would also be breaking but at least of bad practice only. But how to introduce it is not easy: it could be either a new very strange attribute (method may have side effects inside the defining type but not outside) too similar to pure and const (no thanks) or rather a special case for some operators, e.g. a==b statement is never allowed even if opEquals isn't pure. The problem is for example that you want to do the same for operator "+" but not "++", and both are overloaded by opUnary, so the solution is even harder here.

I think my conclusion is leave the thing as it is :)

> Still waiting on D to do something about comparisons between signed and unsigned types, or is having no warning or error the desired behavior?

For me yes it's the desired one.

Implicit casts leading to overflow are a different issue. It looks they are never checked even in @safe environments (I know, @safe is related to memory, not data corruption). C# has checked{} and unchecked{} environments:
https://msdn.microsoft.com/library/khy08726.aspx

But now we're off topic...

Jerry wrote:

> On Tuesday, 7 March 2017 at 21:34:35 UTC, Walter Bright wrote:
>> On 3/7/2017 9:45 AM, Atila Neves wrote:
>>> 1 warning generated.
>>
>> Pretty much all C++ compilers will generate warnings for this. The thing about warnings, though, is they imply that there are situations where the code is acceptable. I can't think of any. It needs to be an error. It should never pass the compiler.
>
> What about Ketmar's example? It seems to have been glossed over.

nobody cares, and half (random approximation) of writers didn't even understood the problem -- see the discussion about "opEquals() purity", "language changes", and other things that have absolutely nothing to do with what i wrote.

On Sunday, 12 March 2017 at 08:03:46 UTC, Jerry wrote:
> What about Ketmar's example? It seems to have been glossed over.

It wasn't.

* The problem was described by Ketmar
* People explained why you can't give the default behavior to that code
* A compromise was proposed and documented in a bug report

> Still waiting on D to do something about comparisons between signed and unsigned types

Don't hold your breath. The fix has been approved, but the compiler devs are all working on other things.

On Sunday, 12 March 2017 at 17:33:23 UTC, Jack Stouffer wrote:
> On Sunday, 12 March 2017 at 08:03:46 UTC, Jerry wrote:
>> What about Ketmar's example? It seems to have been glossed over.
>
> It wasn't.

It was (by walter).

> Don't hold your breath. The fix has been approved, but the compiler devs are all working on other things.

I don't expect anything less than nothing.

On Sat, Mar 11, 2017 at 08:55:12PM +0000, Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Friday, 10 March 2017 at 22:41:43 UTC, H. S. Teoh wrote:
> > The problem is that "<<" was designed to be a bit-shift operator, and as such it has a specific precedence level in the hierarchy of operators.
> 
> Fair point. IIRC Algol68 allowed custom precedence levels. Found this: http://www.kestrel.edu/home/people/meertens/publications/papers/Operator-Priority_Grammar_for_ALGOL_68+.pdf

Custom precedence levels make the language a pain to parse, esp. by external 3rd party tools.  Which generally also means (good) tooling will be harder to come by.  Doesn't seem like a commensurate price with the little replaceable benefit that you get.


> At the other end of the spectrum Pony requires explicit parens for operators outside the most familiar ones ("+", "-", "*"...).

This may not be a bad idea, actually. How many among us can actually memorize the entire precedence hierarchy of C/C++ operators? I certainly can't. Meaning that most of the time you'd already be writing parentheses anyway, just to be sure, so it wouldn't be an onerous requirement to always write them.


T

-- 
My program has no bugs! Only undocumented features...

On Saturday, 11 March 2017 at 19:28:16 UTC, H. S. Teoh wrote:
> So the idea is to analyse the format string at compile-time to determine exactly what functionality is actually used, and instantiate only that. Think of it as a format-string mini-compiler: given a format string and a list of argument types, compile it into the equivalent minimal D code. E.g.:
>
> 	format("abc%sdef", s)
>
> should get compiled into:
>
> 	"abc" ~ s ~ "def"	// N.B.: no floating-point code, no
> 				// width handling, etc.

Sounds good, and it would be more efficient at runtime. But as the type checking is easier, and the interface is the same, I think we could add type checking now and hopefully do the CT parsing later.