On Mon, 15 Jun 2015 22:06:24 +0000, Ola Fosheim Grøstad wrote:

> On Monday, 15 June 2015 at 21:59:43 UTC, ketmar wrote:
>> nononono. i smell #define hell from C and all the problems it brings, like careful ordering of #include.
> 
> Nah. #define does not define constants, but variable macros.
> 
> Constants are constant _everywhere_. If ordering can effect that it isn't a _constant_.

and `version` isn't a constant. it's a version id. it even lives in it's own name space.

On Wed, 17 Jun 2015 17:25:05 +0000, weaselcat wrote:

> sometimes I find 'alias this' quite elegant, such as using alias this to a function. Other times I find it to be a poor hack to get around the lack of struct inheritance.

i agree that it has it's uses, but it's still a weird hack. and it introduces subtle bugs to compiler, like bug #14653, for example. it's overlooked 'cause `alias this` is so hackish...

On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
> and `version` isn't a constant. it's a version id. it even lives in it's own name space.

For no gain whatsoever.

On Wednesday, 17 June 2015 at 17:24:50 UTC, ketmar wrote:
> On Tue, 16 Jun 2015 03:10:01 -0700, Walter Bright wrote:
>
>> I have yet to see a single case of "needing" boolean versions that could not be refactored into something much more readable and maintainable that did not use such.
>
> and i have yet to see such cases for multiplication operator. it's cryptic, it's hard to read, it looks like line noise. isn't this clear and readable?
>
>   a = 5.mul(12);
>
> and now see the stupid line noise, introduced by "*":
>
>   a = 5*12;

:)

Good use-cases for boolean overloads in addition to DSLs:

https://en.wikipedia.org/wiki/Fuzzy_logic
https://en.wikipedia.org/wiki/Three-valued_logic
https://en.wikipedia.org/wiki/Four-valued_logic

etc...

Although I think it might be more readable to have "and", "or" etc as operators. This is actually allowed in C++:

"a && b" <=> "a and b"…

On Thu, 18 Jun 2015 09:57:19 +0000, Ola Fosheim Grøstad wrote:

> Although I think it might be more readable to have "and", "or" etc as operators. This is actually allowed in C++:
> 
> "a && b" <=> "a and b"…

i prefer that to "&&" and "||", tbh, not because i have pascal/oberon background, but 'cause it's harder to make a typo. "|" is binary, "or" is logic. simple and easy.

p.s. and i hate that "true" converts to "1". in many forth systems "true" is "-1", and it's way better. `a&cast(int)true` actually works for the most widely used case (when a.sizeof <= int.sizeof), for examplt.

On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Grøstad wrote:

> On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
>> and `version` isn't a constant. it's a version id. it even lives in it's own name space.
> 
> For no gain whatsoever.

and it can be removed for good if `static if` will be allowed at module level. one of Walter's nightmares, i suppose.

On Thursday, 18 June 2015 at 11:51:04 UTC, ketmar wrote:
> On Thu, 18 Jun 2015 09:57:19 +0000, Ola Fosheim Grøstad wrote:
>
>> Although I think it might be more readable to have "and", "or" etc as operators. This is actually allowed in C++:
>> 
>> "a && b" <=> "a and b"…
>
> i prefer that to "&&" and "||", tbh, not because i have pascal/oberon background, but 'cause it's harder to make a typo. "|" is binary, "or" is logic. simple and easy.

Yes, there is something clean looking about "and"/"or", in my toying with syntaxes I've found that sigils somehow more easily are perceived as noise than words.

It is a very different balance to get right as you add more features.

> p.s. and i hate that "true" converts to "1". in many forth systems "true" is "-1", and it's way better. `a&cast(int)true` actually works for the most widely used case (when a.sizeof <= int.sizeof), for examplt.

I'm all for very strict typing, but converting true to int is by mathematical convention done to 1. On some CPUs it is also the hardware value. *shrugs*

On Thursday, 18 June 2015 at 11:53:31 UTC, ketmar wrote:
> On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Grøstad wrote:
>
>> On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
>>> and `version` isn't a constant. it's a version id. it even lives in it's own name space.
>> 
>> For no gain whatsoever.
>
> and it can be removed for good if `static if` will be allowed at module level. one of Walter's nightmares, i suppose.

I like the idea that "version" is about implementation and "if" is about semantics, but the D version of the concept is a bit raw at the moment.

On Thu, 18 Jun 2015 12:19:03 +0000, Ola Fosheim Grøstad wrote:

>> p.s. and i hate that "true" converts to "1". in many forth systems "true" is "-1", and it's way better. `a&cast(int)true` actually works for the most widely used case (when a.sizeof <= int.sizeof), for examplt.
> 
> I'm all for very strict typing, but converting true to int is by mathematical convention done to 1. On some CPUs it is also the hardware value. *shrugs*

never heard of such convention. ;-)

On 06/18/2015 01:53 PM, ketmar wrote:
> On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Grøstad wrote:
>
>> On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
>>> and `version` isn't a constant. it's a version id. it even lives in
>>> it's own name space.
>>
>> For no gain whatsoever.
>
> and it can be removed for good if `static if` will be allowed at module
> level. one of Walter's nightmares, i suppose.
>

static if is allowed at module level.