This is one of those where I keep hoping someone will pick it up and get the
proposal out there.
-- E
> On Apr 29, 2016, at 8:57 AM, David Hart via swift-evolution
> wrote:
>
> What’s up with this great idea? Can’t see a proposal on swift-evolution
> anywhere.
>
>> On 08 Apr 2016, at 08:15,
What’s up with this great idea? Can’t see a proposal on swift-evolution
anywhere.
> On 08 Apr 2016, at 08:15, Chris Lattner via swift-evolution
> wrote:
>
>
>> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution
>> wrote:
>>
>> If you've ever gotten to the point where you have a suf
+1 I almost fully agree with all your points. However I disagree with your
first point:
What do you mean by: "I think it's more natural to restrict generic type
parameters to the immediate local scope"
To me it feels like an "associated type" so it should be almost equally exposed
in compariso
> On Apr 6, 2016, at 17:13, Brent Royal-Gordon via swift-evolution
> wrote:
>
> Another nice thing about this style is that, in principle, I think it could
> be extended to specify requirements on non-type parameter values.
I had this thought too. The possibilities that this syntax change su
> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution
> wrote:
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an extension,
> maybe for a generic free function or operator, you know what a pa
Because I am a mailing list noob, my email wasn't CC'd to all. So here we go
again:
Big +1 from me.
I expected not to like this syntax but I believe it makes it far clearer. It
always felt backwards to me to have to come up with all the constraints before
the function signature. Maybe this is
These are fantastic proposals! With these in place, there would be precious
little to envy Haskell.
For example, regarding “counter-proposal against making generic parameters
public”, the current behaviour of Swift is essentially a bug, as reported by
Noah Blake (https://bugs.swift.org/browse/
I quite like this variation, so I’m a +1 for that.
However, I think this would be greatly helped if we could define protocol
generics more like type generics like so:
protocol Foo { … }
func anyStringFoo(lhs:Foo) { … }
But yeah, for the more complicated cases, it makes a lot of
Jordan,
Your comments brought up a few more closely related ideas that have been
bubbling under.
To everyone,
Sorry for going beyond topic here. The discussion of the further proposals
below should be taken into their own threads if there's interest. I'm just
trying to motivate what else movi
> I know you're not proposing that feature right now, but want to understand
> how you expect it to work. It looks to me like this starts to enter design
> by contract territory. Would the predicate behave as if it was part of a
> precondition?
I suppose I imagine it as equivalent to a precon
Another +1 to `where` at the end.
On Wed, Apr 6, 2016 at 10:33 PM, Matt Whiteside via swift-evolution <
swift-evolution@swift.org> wrote:
> +1 to moving the `where` clause after the function signature.
>
> -Matt
>
> > On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution <
> swift-evolution@swi
+1 to moving the `where` clause after the function signature.
-Matt
> On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution
> wrote:
>
>
>> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution
>> wrote:
>>
>> If you've ever gotten to the point where you have a sufficiently generic
I like the idea, I find the beginning of a declaration too cluttered and it
obscures the main purpose. Like Brent I am wary of the design by contract
(DBC) bit, `lhs <= rhs`. DBC is probably for a separate discussion, but
moving the where clause would probably help.
-- Howard.
On 7 April 2016 a
Sent from my iPad
On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution
wrote:
>> I would actually move them as far as after everything else, and right before
>> the definition body. For the above function that would mean:
>>
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
I'm hoping this extends to type values.
struct StructWithClosure
{
let closure : (lhs: Element, rhs:Element) -> Range where
Element : Incrementable, Comparable
}
or for that matter, protocol values:
struct StructWithIntCollectionType
{
let collection : C where C : CollectionType, C.Elemen
> I would actually move them as far as after everything else, and right before
> the definition body. For the above function that would mean:
>
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable
It's probably appropriate. Given that, in this example, Bar implicitly
unifies its generic constraint T with Foo's associatedtype T (or,
typealiases T with T), you need to be at least a little careful how you
name your generic constraints.
protocol Foo
{
associatedtype T
}
struct Bar : Foo
{
> On Apr 6, 2016, at 16:52, Erica Sadun via swift-evolution
> wrote:
>
>>
>> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution
>>> mailto:swift-evolution@swift.org>> w
> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution
> wrote:
>
>
>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> I think this is a good idea, though I would put the `where` clause after the
>> function signature:
>>
> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution
> wrote:
>
> I think this is a good idea, though I would put the `where` clause after the
> function signature:
>
> func foo(x: T, y: U) -> Result
>where T.Foo == U.Bar /*, etc. */
> {
> }
A bit of a meta-argument:
It is very c
> Le 6 avr. 2016 à 16:03, Joe Groff via swift-evolution
> a écrit :
>
>
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola wrote:
>>
>> Joe,
>>
>> Just from your experience on this topic, is there any reason not to also
>> move the primary constraints into the trailing `where` clause?
>>
>> So
> On Apr 6, 2016, at 1:21 PM, Pyry Jahkola wrote:
>
>> Joe Groff wrote:
>>
>> It's a judgment call. It's my feeling that in many cases, a generic
>> parameter is constrained by at least one important protocol or base class
>> that's worth calling out up front, so it's reasonable to allow thin
On Apr 6, 2016, at 2:03 PM, Joe Groff via swift-evolution
wrote:
>
>>
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola wrote:
>>
>> Joe,
>>
>> Just from your experience on this topic, is there any reason not to also
>> move the primary constraints into the trailing `where` clause?
> It's a judg
I think the where clause should be moved to the end as you outlined an any
constraints beyond simple statements of conformance to a protocol or
superclass should only be allowed in the where clause. If someone desires
to state simple conformance/superclass for a generic parameter they should
be all
> Joe Groff wrote:
>
> It's a judgment call. It's my feeling that in many cases, a generic parameter
> is constrained by at least one important protocol or base class that's worth
> calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without ba
> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola wrote:
>
> Joe,
>
> Just from your experience on this topic, is there any reason not to also move
> the primary constraints into the trailing `where` clause?
>
> So instead of what you wrote, we'd have it this way:
>
> func foo(x: T, y: U) -> R
> For example, this Standard Library function:
>
> public func + <
> C : RangeReplaceableCollectionType,
> S : SequenceType
> where S.Generator.Element == C.Generator.Element
> > (lhs: C, rhs: S) -> C
>
> would become:
>
> public func + (lhs: C, rhs: S) -> C w
Joe,
Just from your experience on this topic, is there any reason not to also move
the primary constraints into the trailing `where` clause?
So instead of what you wrote, we'd have it this way:
func foo(x: T, y: U) -> Result
where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
{
I don’t see much value in moving them out of the angle brackets but preserving
the position; consider:
// status-quo:
func anyCommonElements
(lhs: T, _ rhs: U) -> Bool
// as-per proposal:
func anyCommonElements
where
T.Generator.Element: Equatable,
T.Generator.Elem
> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution
> wrote:
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an extension,
> maybe for a generic free function or operator, you know what a pa
Even better. +1.
~Robert Widmann
2016/04/06 14:35、Pyry Jahkola via swift-evolution
のメッセージ:
>> On 06 Apr 2016, at 21:30, Developer via swift-evolution
>> wrote:
>>
>> If you've ever gotten to the point where you have a sufficiently generic
>> interface to a thing and you need to constrain
> On 6 Apr 2016, at 19:48, Sean Heber wrote:
>
> This almost seems like it could work so that it didn't even need the
> bracketed parts to be able to figure out the types:
>
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.
I would think it’d just be unconstrained generic parameters - same as this is
now:
func f(lhs: A, _ rhs: B) {}
However I can see how it’d certainly be potentially too confusing. It might be
worthwhile to retain the brackets, but require type restrictions to be moved to
the trailing “where” so
+1. I like the idea of seeing the function signature first, then the
constraints.
> On Apr 6, 2016, at 3:47 PM, Milos Rankovic via swift-evolution
> wrote:
>
>
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> func anyCommonElem
With `where` at the end, the Standard Library function:
public func != <
A : Equatable,
B : Equatable,
C : Equatable,
D : Equatable,
E : Equatable,
F : Equatable
> (lhs: (A, B, C, D
A big +1 to this notation.
> On 06 Apr 2016, at 20:47, Milos Rankovic via swift-evolution
> wrote:
>
>
>> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceT
> This almost seems like it could work so that it didn't even need the
> bracketed parts to be able to figure out the types:
>
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : SequenceType,
>T.Generator.Element: Equatable,
>T.Generator.Element == U.
> On Apr 6, 2016, at 12:30 PM, Developer via swift-evolution
> wrote:
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an extension,
> maybe for a generic free function or operator, you know what a pa
> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution
> wrote:
>
> This almost seems like it could work so that it didn't even need the
> bracketed parts to be able to figure out the types:
>
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>T : SequenceType,
>U : Sequ
This almost seems like it could work so that it didn't even need the bracketed
parts to be able to figure out the types:
func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
T : SequenceType,
U : SequenceType,
T.Generator.Element: Equatable,
T.Generator.Element == U.Generator.El
> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution
> wrote:
>
> func anyCommonElements(lhs: T, _ rhs: U) -> Bool
> where T : SequenceType,
> U : SequenceType,
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> ...
> The same would work for generic types too:
>
> public struct Dictionary
> where Key : Hashable
> {
>...
> }
And I'm not sure if people feel the same as me, but I haven't been happy with
the current way generic arguments (such as Key and Value above) magically
appear in type extension
*grabs paintbrush*
Something that has always bothered me about the generic syntax for functions is
how far the function’s name is from its parameters. There are probably reasons
why the following might not work, but it could address my desire to keep the
name of the thing close to the names of
On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:
> On 06 Apr 2016, at 21:30, Developer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing
> On 06 Apr 2016, at 21:30, Developer via swift-evolution
> wrote:
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an extension,
> maybe for a generic free function or operator, you know what a pain t
If you've ever gotten to the point where you have a sufficiently generic
interface to a thing and you need to constrain it, possibly in an extension,
maybe for a generic free function or operator, you know what a pain the syntax
can be for these kinds of operations. For example, the Swift book
46 matches
Mail list logo
