Doesn't make any sense?

foreach(a; x)

if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.

It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.

On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote:
> Doesn't make any sense?
>
> foreach(a; x)
>
> if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.
>
> It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.

You can already do this for any type you define:

class Foo
{
  auto iterate() { return only(this); }
  alias iterate this;
}

Can you give examples of code that is awkward today that would be simplified with your proposal? I don't expect people to give full cost-benefit analyses for every suggestion, but it'd be nice if you could at least mention some of the upsides.

On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote:
> Doesn't make any sense?
>
> foreach(a; x)
>
> if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.
>
> It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.

on the otherhand some programmer might want to get informed buy an error-msg, if he accidentally used a non-iteratable variable for `foreach`-iteration. To avoid a silent bug

On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
> On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote:
>> Doesn't make any sense?
>>
>> foreach(a; x)
>>
>> if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.
>>
>> It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.
>
> You can already do this for any type you define:
>
> class Foo
> {
>   auto iterate() { return only(this); }
>   alias iterate this;
> }
>
> Can you give examples of code that is awkward today that would be simplified with your proposal? I don't expect people to give full cost-benefit analyses for every suggestion, but it'd be nice if you could at least mention some of the upsides.

And then you can generalize this for any type

auto elseOnly(T)(T t) {
  import std.range: isInputRange;
  static if (isInputRange!T) {
    return t;
  } else  {
    import std.range: only;
    return only(t);
  }
}

foreach(i; 3.elseOnly) {
}

foreach(i; [1, 2, 3].elseOnly) {
}


Cheers
- Ali

On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
> On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote:
>> Doesn't make any sense?
>>
>> foreach(a; x)
>>
>> if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.
>>
>> It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.
>
> You can already do this for any type you define:
>
> class Foo
> {
>   auto iterate() { return only(this); }
>   alias iterate this;
> }
>
> Can you give examples of code that is awkward today that would be simplified with your proposal? I don't expect people to give full cost-benefit analyses for every suggestion, but it'd be nice if you could at least mention some of the upsides.

The upside is that it is a composite pattern and does not require any extra code to use preexisting functionality. There is no downside, which is an upside.



foreach(a; x)
{
   // uses a

}

gets directly converted to

{
   // uses x
}

by a simple renaming/aliasing of a to x and so it cannot require any more issues than what already exists.

Your method requires one to have access to all type definitions, which is not the case.



I do not know why I would be required to specify a use case to justify the usability. Most things are not usable until they are invented. Most people did not know how useful the hammer would be until someone created it. You have to build it for them to come. I have my use cases which is why I came up with the idea in the first place. I needed a hammer but no one invented it. If I give you my use case then there would be two main outcomes: You attempt to find a workaround for the use case or claim that it is not applicable. These are the "I have a rock that should work as good as that hammer thingy you want" and "Hammers are useless".

If you can't find validity in the suggestion based on it's own inherent usefulness than the only way I can convince you is to provide examples that you actually find useful... that makes it difficult on my part and is not fair to me.

On Thursday, 24 May 2018 at 23:03:34 UTC, meppl wrote:
> On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote:
>> Doesn't make any sense?
>>
>> foreach(a; x)
>>
>> if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.
>>
>> It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.
>
> on the otherhand some programmer might want to get informed buy an error-msg, if he accidentally used a non-iteratable variable for `foreach`-iteration. To avoid a silent bug

In this case it cannot be a bug. The foreach is simply ignored/reduced. It would be impossible for any bug to creep in(assuming no compiler bugs) in such cases.

foreach(a; x)
{
   x[]
}

would be some type of potential bug... but that bug would also exist without the loop. If x is not an array then the the foreach effectively is removed and a is just auto a = x;

Any code that uses x would fail just as much as using a and no more except.

On Thursday, 24 May 2018 at 23:08:39 UTC, aliak wrote:
> On Thursday, 24 May 2018 at 23:02:00 UTC, Neia Neutuladh wrote:
>> On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote:
>>> Doesn't make any sense?
>>>
>>> foreach(a; x)
>>>
>>> if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm.
>>>
>>> It unifies the concepts so that one does not have to worry if x is an array or not and can offer no harm since when x is not an array everything simply reduces to an an alias of x.
>>
>> You can already do this for any type you define:
>>
>> class Foo
>> {
>>   auto iterate() { return only(this); }
>>   alias iterate this;
>> }
>>
>> Can you give examples of code that is awkward today that would be simplified with your proposal? I don't expect people to give full cost-benefit analyses for every suggestion, but it'd be nice if you could at least mention some of the upsides.
>
> And then you can generalize this for any type
>
> auto elseOnly(T)(T t) {
>   import std.range: isInputRange;
>   static if (isInputRange!T) {
>     return t;
>   } else  {
>     import std.range: only;
>     return only(t);
>   }
> }
>
> foreach(i; 3.elseOnly) {
> }
>
> foreach(i; [1, 2, 3].elseOnly) {
> }
>
>
> Cheers
> - Ali

cool, and this is optimal, right? non-arrays are not converted in to arrays, etc?

On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions wrote:
> the idea in the first place. I needed a hammer but no one invented it. If I give you my use case then there would be two main outcomes: You attempt to find a workaround for the use case or claim that it is not applicable. These are the "I have a rock that should work as good as that hammer thingy you want" and "Hammers are useless".

3rd outcome: noobs like me who read the forums who benefit from such discussion.

Of course, you could be as disinterested in the 3rd outcome as you are the 1st and 2nd, and that's completely fair.

Jordan

On Thursday, 24 May 2018 at 23:22:56 UTC, IntegratedDimensions wrote:
> If you can't find validity in the suggestion based on it's own inherent usefulness than the only way I can convince you is to provide examples that you actually find useful... that makes it difficult on my part and is not fair to me.

You are asking us all to do work for you. You're asking everyone to learn about this new language element. (And yes, we would have to learn, since it means the compiler is less able to find errors in our code, because more code is valid.) You're asking Walter Bright or another compiler developer to implement this feature for you, and write the tests, and write the documentation, and support this new code for years.

This is not an impossibly huge request, but it isn't trivial by any means. There are two socially acceptable ways to get people to implement something you want: convince them it's worthwhile, or pay them.

Compare: there's no socket.io client or server library for D. You should implement one. Does my saying so make you inclined in any way to write a socket.io library?

On Thursday, 24 May 2018 at 23:28:59 UTC, IntegratedDimensions wrote:
> cool, and this is optimal, right? non-arrays are not converted in to arrays, etc?

Seems they are not converted no, but it loops like an extra variable is stored though (a bool to denote existence of a value)

https://github.com/dlang/phobos/blob/v2.080.0/std/range/package.d#L9512