On Friday, 4 April 2014 at 09:07:31 UTC, Dicebot wrote:
> On Friday, 4 April 2014 at 08:16:20 UTC, Paulo Pinto wrote:
>> Says who? And slow to whom?
>>
>> 1 - Write correct code
>>
>> 2 - Use a profiler, if the code isn't fast enough for the use case being written for
>>
>> 3 - If desired use case isn't there, use the profiler information to improve the specific hotpaths in need of tuning.
>>
>> I see too many people micro-optimize for nothing.
>>
>> --
>> Paulo
>
> While this is true in general, spotting performance overhead from using bigints everywhere in profiler can be rather tricky because it will be evenly spread across the program. Micro-optimizations are bad but this is not very practical example.

To pick up on the bigints example, most compilers only use them if they don't fit into registers.


--
Paulo

okay, awesome, I guessed correctly then. (on where to find it anyway).


On Fri, Apr 4, 2014 at 11:16 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 4/4/2014 12:23 AM, Rory McGuire wrote:
>
>> On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright <newshound2@digitalmars.com <mailto:newshound2@digitalmars.com>> wrote:
>>
>>     You can disable the implicit conversion to int with this scheme. The
>> alias
>>     this only takes effect if there is no other member that will take the
>> operation.
>>
>> What is the exact method of disabling the implicit cast? I had a look
>> after you
>> sent your last mail. Didn't find anything in the spec.
>>
>
> It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet.
>

Walter Bright:

> Because every cast breaks the type system. A type system that requires too many casts for normal things is NOT a type safe system.
>
> I have explained this on numerous occasions.

You have discussed many times about the unsafety of casts and I agree with your point of view. I try to reduce the number of casts as much as possible in my code (and recently I have replaced many "cast(double)x" with nice "double(x)", as time passes D allows to remove more and more casts from the code, this is an improvement).

You see I care of casts also from the little casts statistic I've done on your Warp:
http://forum.dlang.org/thread/lhf0u6$2r80$1@digitalmars.com?page=3#post-wjjivmmeyeismgkntwsj:40forum.dlang.org
Or from answers I keep giving in D.learn, where I suggest to minimize the usage of casts:
http://forum.dlang.org/thread/efbjrtwqywkhfybmyvxy@forum.dlang.org

But since I follow D development and I write D code I don't remember any kind of discussion regarding the specific disadvantages of a stronger typed enum. This means answering questions like: what does it happen if D enums become strongly typed? How many casts is this going to cause in D code? Is it true that such enum casts are going to be worse than type unsafety of the current design? I don't remember seeing any little study that shows that stronger casts in D increase a lot the number of casts. Perhaps this little study was done before I have started to use D1 and I have missed it.

I suspect that in my D code most cast usage does not need casts if you replace them with stronger casts as the "enum class" of C++11, but I have no proof of this.

Bye,
bearophile

> I suspect that in my D code most cast usage does not need casts if you replace them with stronger casts as the "enum class" of C++11, but I have no proof of this.

Too much casting. I meant to say:

I suspect that in my D code most usages of enum don't need casts if you replace them with stronger enums (like the "enum class" of C++11), but I have no proof of this.

Bye,
bearophile

On Friday, 4 April 2014 at 07:43:22 UTC, Paulo Pinto wrote:

> Java came up with it most likely as it was the way in Smalltalk.

That's right. As Smalltalk is dynamically typed it is not an issue there anyway and Java to begin with had to parameterized types till JDK4.

>I guess you need to be more up to date to Scala news. :)
>https://groups.google.com/forum/m/#!msg/scala-internals/6HL6lVLI3bQ/IY4gEyOwFhoJ
>https://github.com/lampepfl/dotty

Interesting. But it kind of looks like yet another academical thing similar to Scala. To me Kotlin is the better "Scala done right" language. But I won't play with it until I see its compiler speed being a lot better than with Scala ...

04-Apr-2014 13:16, Walter Bright пишет:
> On 4/4/2014 12:23 AM, Rory McGuire wrote:
>> On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright <newshound2@digitalmars.com
>> <mailto:newshound2@digitalmars.com>> wrote:
>>
>>     You can disable the implicit conversion to int with this scheme.
>> The alias
>>     this only takes effect if there is no other member that will take
>> the operation.
>>
>> What is the exact method of disabling the implicit cast? I had a look
>> after you
>> sent your last mail. Didn't find anything in the spec.
>
> It's supposed to be by adding your own opImplicitCast overload, but that
> isn't implemented yet.

The difference between opImplictCast and alias this being ... ?

-- 
Dmitry Olshansky

First use alias this go "import" functionality transparently. Then use
opImplicitCast to set what can be implicitly casted to.
On 04 Apr 2014 12:45 PM, "Dmitry Olshansky" <dmitry.olsh@gmail.com> wrote:

> 04-Apr-2014 13:16, Walter Bright пишет:
>
>> On 4/4/2014 12:23 AM, Rory McGuire wrote:
>>
>>> On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright < newshound2@digitalmars.com <mailto:newshound2@digitalmars.com>> wrote:
>>>
>>>     You can disable the implicit conversion to int with this scheme.
>>> The alias
>>>     this only takes effect if there is no other member that will take
>>> the operation.
>>>
>>> What is the exact method of disabling the implicit cast? I had a look
>>> after you
>>> sent your last mail. Didn't find anything in the spec.
>>>
>>
>> It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet.
>>
>
> The difference between opImplictCast and alias this being ... ?
>
> --
> Dmitry Olshansky
>

On Friday, 4 April 2014 at 09:16:26 UTC, Walter Bright wrote:
> It's supposed to be by adding your own opImplicitCast overload, but that isn't implemented yet.

Wait, this is back? What else did the community get wrong when trying to interpret discussions?

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

Previously proposed, but now dropped:

    * opImplicitCast
    * Separating arrays and slices (T[new]) (see NG:digitalmars.D/95225)
        Demise of T[new] NG:digitalmars.D/98602
    * Make references and arrays library types (see NG discussion)
    * this() for structs.
    * Make array literals immutable.
    * Remove 'new'.
    * Remove C-style struct initializers.

On 4/4/2014 3:24 AM, bearophile wrote:
> You see I care of casts also from the little casts statistic I've done on your
> Warp:
> http://forum.dlang.org/thread/lhf0u6$2r80$1@digitalmars.com?page=3#post-wjjivmmeyeismgkntwsj:40forum.dlang.org

Most of the casts in Warp come from the workarounds I had to do to get around the auto-decode of std.array.front(). I have designed byChar, byWchar and byDchar ranges for Phobos to get around this issue, but that is stalled now because of the messed up design of ranges.

None of that has anything to do with enums.


> But since I follow D development and I write D code I don't remember any kind of
> discussion regarding the specific disadvantages of a stronger typed enum.

Here's one:

  enum Index { A, B, C }
  T[Index.max] array; // Error: Index.max is not an int
  ...
  array[B] = t;   // Error: B is not an int


And another:

  array[A + 1] = t; // Error: incompatible types Index and int

And another:

  enum Mask { A=1,B=4 }

  Mask m = A | B;   // Error: incompatible operator | for enum

and on it goes. These are routine and normal uses of enums.


> This means answering questions like: what does it happen if D enums become strongly
> typed? How many casts is this going to cause in D code? Is it true that such
> enum casts are going to be worse than type unsafety of the current design?

Yes, because I have to fill the above code with cast(int), and you are well aware that such blunt casting destroys all type safety.

And besides, even if such strongly typed enums were a good idea, making such a change would be an utter disaster for existing code. It is out of the question.

On Friday, 4 April 2014 at 18:02:02 UTC, Walter Bright wrote:
> Here's one:
>
>   enum Index { A, B, C }
>   T[Index.max] array; // Error: Index.max is not an int
>   ...
>   array[B] = t;   // Error: B is not an int
>
>
> And another:
>
>   array[A + 1] = t; // Error: incompatible types Index and int
>
> And another:
>
>   enum Mask { A=1,B=4 }
>
>   Mask m = A | B;   // Error: incompatible operator | for enum
>
> and on it goes. These are routine and normal uses of enums.

It's trivial to write an EnumMemberValue template that convert the enum member to its underlying value at compile time. Also, if I remember correctly, min and max are terribly broken for enums in the first place.