On 13.04.19 10:22, Nick Sabalausky (Abscissa) wrote:
> On 4/11/19 7:23 PM, Tony wrote:
>> On Tuesday, 9 April 2019 at 06:23:26 UTC, aliak wrote:
>>>
>>
>>> [0] https://swift.org/blog/swift-5-released/
>>
>> Still, no (official at least) Windows support. Don't know if that is because there is no interest in broadening the usage or if it is considered too difficult or not worth the effort to do so.
>>
> 
> It's probably because there's nothing in Swift that appeals to the same sheeple who consider it perfectly normal and acceptable in 2019 to hand your entire machine over to a randomly-activated process that hijacks all control over your own personal physical property (including the ability to close the lid, unplug it, and stick it into its own stupid carrying case so you can drive the F*&*ck home without corrupting the entire freaking operating system) for an *unspecified* number of **HOURS**, while requiring both fast internet access and ZERO interactivity, so it can perform the absolute most poorly-implemented update process **in computing history**, at its own discretion, while silently disabling your complex, hard-to-discover, unintuitively-activated pro-privacy settings.

I'm not sure why similar arguments do not apply to users of Apple devices.

On Sunday, 14 April 2019 at 00:27:18 UTC, Timon Gehr wrote:
> There are of course other reasons why you would want to add functions with a simple implementations, I already mentioned standardization of function names, also, e.g. filter!isOdd is both faster to read and easier to type than filter!(x=>x&1).

Would not you check the function definition if you saw `isOdd()` in the code?

> Furthermore, it's just not nice when you are solving a problem and notice that a lot of functions you need to naturally express it are missing from the standard library and you need to add them to your own utility library first, presumably being too lazy to add the correct template constraints.

Maybe your math utils library(ies) would be popular on dub. Even if some template constraints are missing, they would probably get fixed over time by some willing contributing users.

On 13.04.19 07:18, H. S. Teoh wrote:
> Personally, even though I understand perfectly well what (x & 1) means,
> I much rather write it as (x % 2) instead and let the optimizer
> implement it as (x & 1)

(x % 2) and (x & 1) are not equivalent in all contexts. The modulo operator is insane, and there isn't really a good way to fix it because the hardware is doing it wrong.

On 14.04.19 02:42, mate wrote:
> On Sunday, 14 April 2019 at 00:27:18 UTC, Timon Gehr wrote:
>> There are of course other reasons why you would want to add functions with a simple implementations, I already mentioned standardization of function names, also, e.g. filter!isOdd is both faster to read and easier to type than filter!(x=>x&1).
> 
> Would not you check the function definition if you saw `isOdd()` in the code?
> ...

Probably not. What would be the trigger for that?

>> Furthermore, it's just not nice when you are solving a problem and notice that a lot of functions you need to naturally express it are missing from the standard library and you need to add them to your own utility library first, presumably being too lazy to add the correct template constraints.
> 
> Maybe your math utils library(ies) would be popular on dub. Even if some template constraints are missing, they would probably get fixed over time by some willing contributing users.

Maybe. However, often, the quickest way to make the thing I was working on work with sufficient code quality is not actually to implement the missing standard library functions, even though it would have been easier with those functions there. (E.g., compute the thing with a a few for loops instead of with a more elegant and readable range-based solution.) I'll consider writing some libraries in the future, but right now I don't really get enough of my productive time to work on projects I already started, such as getting better tuple support, and I'd really prefer obvious omissions to be in the standard library. I see that scan has finally been added, but I'm a bit disappointed it was called cumulativeFold.

Here, I was mainly objecting to the general idea that functions that are simple to implement in terms of a few other functions/built-in operators have no business being in the standard library. (This has come up before.) It's not even consistently applied in Phobos. E.g., there is max and min even though they are trivially implemented in terms of each other by switching around the comparison predicate, but it would clearly be ridiculous to require this by arbitrarily picking one over the other. On the other hand, we have until, but not takeWhile, even though it is more common to want to specify the kinds of elements that you like instead of a condition on the first one that you don't want.

On 4/13/2019 7:20 PM, Timon Gehr wrote:
> It's not even consistently applied in Phobos.

That's a general problem with anything that's been worked on for 20 years by successive waves of different people with different ideas. Phobos has accumulated a lot of technical debt.

BTW, did you know that Phobos used to contain secant() and cosecant() functions? I removed them :-)

On 4/13/2019 5:27 PM, Timon Gehr wrote:
> My point exactly. x & 1 is not the best implementation of isOdd for all integer-representing types of x,

It is for all the basic integral types in D, and I would expect anyone implementing their own integral type to make x&1 work.

I.e. when you make your own integral type, the onus is on you to make the integer operators do the expected thing with it. D's template constraints should be good enough to recognize x&1 and make it efficient for the user defined type implementation.

isOdd() would be problematic for floating point types, which is a reason to avoid doing it for them, so people don't get surprised. (What is isOdd(infinity) supposed to do? true? false? throw exception? abort? launch nuclear missiles?)

On Friday, 12 April 2019 at 07:04:07 UTC, Julian wrote:
> On Friday, 12 April 2019 at 06:14:05 UTC, Nick Sabalausky (Abscissa) wrote:
>> Parson me here, but: Bullshit.
> ...
>> But here's the problem: That's your superpower. It's enviable, it's impressive,
> ...
>> In short: I...know...low-level. Period.
>>
>> And yet, even *I* look at "x & 1" or "x % 2", and my first instinct is..."WTF is going on...?
>
> This is some incredibly strident language to deploy in favor of
> isOdd/isEven. Is isOdd actually Julius Caesar? Is this speech
> directed at Brutus? After this kind of talk, it would be an
> embarrassment if the other party said "OK, actually I agree."
> The crowd expects a ritual suicide.

I'm more in the Walter and Andrei camp here, but I could see that in a different context isOdd would be a useful contribution to the standard library.

When people have strong emotional reactions to technical questions then quite often it's an indication that it's a question of values that has a technical expression.

From a narrowly technical perspective there's no way to decide I think - it's not like one choice strictly dominates another.  So you have to make a choice based on what's most important to you, and that's what values are about.

I think for me and in my commercial context it's the values that are the most appealing aspect of D, with the technical aspects of D as it stands today being an expression of those.

For example making D accessible to people who are put off by discomfort - it's not like anyone here thinks yes the user must suffer.  It's just that some other things are much more important to the leadership and community and choices are made accordingly.

It's a terrible idea to try to be all things to all people, and a much better idea to be the thing that you uniquely are destined to be.  Because the world is quite large these days and having an inordinately high appeal to part of the population is a better position to be in than being moderately appealing to everyone.

An inordinate love of comfort is the civilisation-killer and it's not great for an enterprise either.  There's a growing movement to embrace discomfort and they might just have something.

On 14.04.19 10:27, Walter Bright wrote:
> On 4/13/2019 7:20 PM, Timon Gehr wrote:
>> It's not even consistently applied in Phobos.
> 
> That's a general problem with anything that's been worked on for 20 years by successive waves of different people with different ideas. Phobos has accumulated a lot of technical debt.
> ...

The right answer here really isn't to remove the `max` function.

> BTW, did you know that Phobos used to contain secant() and cosecant() functions? I removed them :-)

That seems like a bad idea even assuming your criteria. `sec(x)` rounds once (if implemented correctly) while `1/cos(x)` rounds twice.

Phobos also contains `sin` and `cos` functions. Please don't remove either of them.

On 14.04.19 10:37, Walter Bright wrote:
> On 4/13/2019 5:27 PM, Timon Gehr wrote:
>> My point exactly. x & 1 is not the best implementation of isOdd for all integer-representing types of x,
> 
> It is for all the basic integral types in D, and I would expect anyone implementing their own integral type to make x&1 work.
> ...

What if it is stored as a series of primes and exponents in the number's prime factorization?

> I.e. when you make your own integral type, the onus is on you to make the integer operators do the expected thing with it. D's template constraints should be good enough to recognize x&1 and make it efficient for the user defined type implementation.
> ...

But this is not the case now. It is not possible to require specific values as function arguments in template constraints. And it would be awfully strange. `x&1` is an implementation detail that works well for built-in integer types, `isOdd` is the abstract meaning. What you are proposing to do is to take the implementation and elevate it to the abstract level. It's a bit like making the only way to call the library `sort` routine to manually implement some sorting algorithm which is then magically replaced by a library call. Or if we stick with the same example, you would seem to be arguing in favor of removing `r.front`, `r.popFront` and `r.empty` and forcing every range type to support `r[0]`, `r=r[1..$]` and `r.length==0` instead, even those that don't support indexing nor slicing, nor have a way to compute length in constant time.

Note that the issue isn't that I am not able to understand or write the implementation without thinking about it. I also immediately see that `x&&!(x&x-1)` checks whether x stores a power of two, or that x&-x extracts the least significant bit that's set to one.

> isOdd() would be problematic for floating point types, which is a reason to avoid doing it for them, so people don't get surprised. (What is isOdd(infinity) supposed to do? true? false? throw exception? abort? launch nuclear missiles?)

Probably floating-point types shouldn't have an `isOdd` function, because they are not integer-representing types and rounding can cause `isOdd` to switch from true to false in a way that goes against the way addition of odd/even integers is supposed to work. However, if we check Wikipedia, it is clear what the function should do, if it would be implemented:

https://simple.wikipedia.org/wiki/Odd_number (simple Wikipedia because in main wikipedia, "odd number" redirects to "parity".)
---
An odd number is an integer which is not a multiple of two;
---

It should return `false` for every input that is not an integer.

On Sunday, 14 April 2019 at 08:37:26 UTC, Walter Bright wrote:
> On 4/13/2019 5:27 PM, Timon Gehr wrote:
>> My point exactly. x & 1 is not the best implementation of isOdd for all integer-representing types of x,
>
> It is for all the basic integral types in D, and I would expect anyone implementing their own integral type to make x&1 work.

I personally would expect bitwise operations to operate on the underlying bit pattern instead of its two's-complement equivalent representation.