www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6148] New: Make templates smarter about instantiating with implicitly convertible arrays

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6148

           Summary: Make templates smarter about instantiating with
                    implicitly convertible arrays
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg gmx.com> 2011-06-11 20:05:35
PDT ---
At present, most of range-based algorithms fail with static arrays and const or
immutable dynamic arrays. This is because when a templated function attempts to
instantiate them, it uses their _exact_ type, when they can work just fine as
long as the appropriate dynamic array is used instead. For instance, find's
basic definition for looking for a range within another range looks like this:

R1 find(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle)
if (isForwardRange!R1 && isForwardRange!R2
        && is(typeof(binaryFun!pred(haystack.front, needle.front)) : bool)
        && !isRandomAccessRange!R1)
{...}

static arrays and const or immutable dynamic arrays will fail because they
aren't input ranges. However, if find had a special overload for arrays such as

R1 find(alias pred = "a == b", R1, E)(R1 haystack, const(E)[] needle)
if (isForwardRange!R1
        && is(typeof(binaryFun!pred(haystack.front, needle.front)) : bool)
        && !isRandomAccessRange!R1)
{...}

then static arrays and const or immutable dynamic arrays would work, because
they would implicitly convert to a dynamic array of const elements of the same
type of element that they have. And in fact, as long as the static array isn't
const or immutable, it would convert to a mutable dynamic array of the same
element type. I would _very_ much like to see the compiler be smart enough to
instatiate templates with such dynamic arrays when given static arrays or const
or immutable dynamic arrays which would otherwise fail.

I don't know what the best way to handle this is given that templates always
instantiate with their exact type at this point, and there _might_ be a case
where you'd actually _want_ to instantiate one with a static array or an
immutable or const dynamic array. If it's a problem to disallow static arrays
and const or immutable arrays as the type that a template instantiates with
(since they'd be converted over to the most mutable dynamic array which they
could implicitly convert to), then perhaps the solution is to make a second
pass through the template instantiation if it fails with a static array or a
const or immutable dynamic array and try it with the most mutable array type
which they can be implicitly converted to. And then if _that_ works,
instantiate it with that type.

Regardless, it would be _highly_ desirable to make it possible for static
arrays and const or immutable dynamic arrays to instantiate templates with the
most mutable type of array that they will implicitly convert to. Otherwise, the
only way to get around the problem is either to overload every range function
explicitly for arrays or to print template error messages when someone
accidentally uses a static array or a const or immutable dynamic array. Neither
of those scenarios is particularly pleasant. These types of arrays _should_
work, but because templates are currently always so exact, even when they don't
need to be, they don't work. So, please make it possible for them to
instantiate the templates appropriately

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6148



--- Comment #1 from Jonathan M Davis <jmdavisProg gmx.com> 2011-06-11 20:06:08
PDT ---
Related: http://d.puremagic.com/issues/show_bug.cgi?id=4971

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6148


kennytm gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm gmail.com


--- Comment #2 from kennytm gmail.com 2011-06-11 23:23:31 PDT ---
Bug 5666?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6148



--- Comment #3 from Jonathan M Davis <jmdavisProg gmx.com> 2011-06-11 23:31:20
PDT ---
Yeah. Bug# 5666 is related as well. Both bug# 4971 and bug# 5666 deal with
specific instances where this enhancement would fix the problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6148


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com


--- Comment #4 from Steven Schveighoffer <schveiguy yahoo.com> 2011-06-12
11:24:51 PDT ---
Also, see bug 4998 as a possible solution, it can be modified to include more
general cases besides literals.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 12 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6148


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #5 from Jonathan M Davis <jmdavisProg gmx.com> 2012-01-20 23:21:33
PST ---
I believe that the recent changes to IFTI to make dynamic array types
tail-const for IFTI essentially fixes this. The issue with static arrays
remains, but I'm increasingly convinced that not havin static arrays
automatically treated as dynamic arrays with range-based functions is  _good_
thing, since they're not ranges, and slicing them can be dangerous. If
anything, I'd argue that static arrays should _never_ implicitly convert to
dynamic arrays and that they should always have to be explicitly sliced to do
the conversion.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 20 2012