[Swift-devel] Feature proposal: struct constructors

[Tim Armstrong]

I guess it may cause some confusion, but it's the standard term in
functional programming too, e.g.
https://wiki.haskell.org/Constructor#Data_constructor

Mihael, in Swift/T types and functions are in the same namespace so it
isn't possible to have a function with the same name as a type.

This is something else we should probably standardise on - does Swift/K has
separate namespaces for functions and types?  I think we could solve the
ambiguity by just having struct definitions automatically define a function
in the function namespace.

Regardless, CamelCase is probably reasonable for user-defined types.
Thoughts?

- Tim

On Wed, Feb 4, 2015 at 1:05 PM, Ketan Maheshwari <ketan at mcs.anl.gov> wrote:

> I would suggest we change the naming from constructors to something else
> as it has some associated OO connotations.
>
> On Tue, Feb 3, 2015 at 4:54 PM, Tim Armstrong <tim.g.armstrong at gmail.com>
> wrote:
>
>> Hi All,
>>   While designing a location-aware feature for Swift/T Justin and I came
>> across a scenario where we wanted to use Swift structs, but where it was
>> very painful to assign each element individually.  To give you an idea:
>>
>> type foo {
>>   int x;
>>   int y;
>> }
>>
>> foo bar;
>> bar.x = 1;
>> bar.y = 2;
>>
>> I'm looking at adding a feature where we can fill in a structs fields
>> with a single expression.
>>
>> We could do them the C-style way, but that doesn't allow us to use them
>> without defining a new variable (the issue is that {} doesn't specify the
>> intended type, meaning it needs to come from context):
>>
>> foo bar = { 1, 2 };
>>
>> I was thinking  that we should just have types function as named
>> constructor functions.  There's precedent both in object-oriented languages
>> and with Haskell's algebraic data types.  Now you can just use this
>> expression wherever needed:
>>
>> foo(1, 2)
>>
>> Thoughts?  I'm reluctant to add new incompatibilities with Swift/K, but
>> this seems like it would be really clunky otherwise.
>>
>> - Tim
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150204/86784c2c/attachment.html>