www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2733] New: Unclear semantics of template value parameters

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

           Summary: Unclear semantics of template value parameters
           Product: D
           Version: 2.025
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid, spec
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: samukha voliacable.com


The following code compiles but the generated binary is not correct.

import std.stdio;

void foo(string s)()
{
    writefln(s);
}

void main()
{
    string s = "test";
    foo!(s);
}
----
Prints nothing. In less trivial cases, passing non-const arguments to value
parameters causes data corruption/access violations.

It is not defined whether the argument should be passed by alias or the code
should fail to compile complaining about the argument not being evaluatable at
compile time.


-- 
Mar 15 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2733


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com




------- Comment #1 from smjg iname.com  2009-04-01 04:53 -------
Non-alias template arguments are, by definition, compile-time constants.  s
isn't a compile-time constant - it's a mutable reference to immutable data.  So
this shouldn't compile.


-- 
Apr 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2733





------- Comment #2 from samukha voliacable.com  2009-04-01 05:13 -------
I'm not that sure anymore. Actually, I wouldn't mind if they were passed by
alias. Then, I could write simply

template foo(string s)
{}

instead of

template foo(alias s) if (isString!(s))
{}

If I want to restrict template arguments to statically known values, I can use
a isCompileTime constraint

template foo(string s) if (isCompileTime!(s))
{
}


-- 
Apr 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2733





------- Comment #3 from smjg iname.com  2009-04-01 07:05 -------
(In reply to comment #2)
 If I want to restrict template arguments to statically known values, I can use
 a isCompileTime constraint

Templates with non-alias parameters are instantiated by value at compile-time in the first place. What you're proposing would be a radical change to this. You could try defining that such a template may be instantiated either by value or by alias. However, this is effectively creating two mutually incompatible templates, and it can be confusing to try to work out which is being instantiated. I can't think of a practical use case for passing a string by alias in a function template, but I'm guessing there's a use for it in templates of some kinds. The question is whether there are enough use cases for syntactic sugar to be worthwhile, but it could look something like template foo(string alias s) .... --
Apr 01 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2733


Christian Kamm <kamm-removethis incasoftware.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kamm-removethis incasoftwar
                   |                            |e.de
            Version|2.025                       |1.045




--- Comment #4 from Christian Kamm <kamm-removethis incasoftware.de> 
2009-06-28 00:14:00 PDT ---
I changed the version to a D1 one as it is also accepts-invalid there.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 28 2009